[Feature Requests] Auto Layer improvements + Auto Tiles for Tile Layers

[Gamer-XP]

I'm trying to use LDTK to make platformer levels, and I've encountered quite a lot of issues with auto tiles so far. Thing is, if your tilesets are not RPG-like and share exactly same layout - they are mostly impossible to use properly with LDTK. This is one of tilesets I'm using for my platformer game. You can imagine it will be near impossible to make all tilsets match same layout to work with autotiles when they look like this:

There are quite a lot of minor things that ruins the conveience of such a great tool.

Related to existing auto-rules:

1. For each rule, there should be an option that disable tile overlapping. When enabled, if current rule takes 2x2 space - other rules should consider whole 2x2 space as already filled and not try to add another tile in it. This is really important when you have some big tile chunk that are not supposed to be overwritten by other tiles. As an example, you can check LDTK's example project AutoLayer_2_stamps. Those big 2x2 tiles actually still have 1x1 tiles drawn below them. This is both bad for performance, may look bad if tile is not completely opaque/filled and may break the whole look if rule order require 1x1 tiles to be lower in the priority order.
2. Not being able to swap used tileset for the auto layer makes it near impossible to use when your tilesets are too different to swap. I suggest adding list of supported tilesets for each auto layer, so you can define different rules for each and be able to swap between them. Swapping non-compatible tilesets will erase all existing data if it exists.
3. When you have a lot of rules - making any changes to them freezes LDTK for 1-2 seconds on each click. Can it be optimized somehow, or is it haxe's expected performance?
4. Will be great is random tile selection support not only individual tiles, but random tile areas (for example, for cases where top of the ground is 1x2 area and you want to randomly choose between them)

And here is some extra functionality that is very similar to rules, but will work for normal tile layers.

Idea is that you have separate auto-tiles for normal tile layers. I expect it to work this way:

1. You create an enum assign it to the tileset you want to use with auto-tiles
2. You mark tiles on the tileset with this enum as needed (grass, dirt, water, etc)
3. In the tileset itself, you can create rules that use this enum the same way int grid use its values
4. When this tileset is selected in the tile layer, you have extra tiles on top that match with the enum (grass, dirt, etc).
5. If you draw those enum-based tiles - they are replaced with actual tile images according to rules. Neighbour tiles are modified ONLY if they are same enum-based tiles internally.
6. If you replace auto-tile with some manual tile - it will check neighbour auto-tiles and update them if needed, the same way as rules do. But, if enum values of old and new tile are the same - there is no need to update anything.

With this, you'll have a very quick way to draw big areas automatically using great existing auto-rules, but will also have full control over modifying it later manually, which is must-have for relatively complex tilesets and fine-tuning.

I understand this is a huge list of thing, but if, at leats, some thing are actually implemented - it will still improve overall workflow.

[dudeax]

Bump for disabling tile overlapping, this would be extremely useful for more complex stamps.

[deepnight]

Hi, Right now, I don't plan to support the tile overlapping part because this leads to some very significant performance issues.

Basically, rules are evaluated from left to right, top to bottom. Supporting "break-on-match" on multiple cells means that a rule could mark cells as occupied backward (if you have a 2x2 stamp, but with pivot point placed in the lower-right corner). It's a bit hard to explain quickly, but I tried to implement that and it went far and really broke many rules paradigms.

[Gamer-XP]

Can you evaluate rules in waves? Like:

1. First rule for all tiles
2. Second rule to all tiles

Instead of

1. All rules for tile 1
2. All rules for tile 2

I feel like it should not require to to re-evaludate already evaluated tiles... probably?

[deepnight]

I'm not sure to understand but that's how it's currently done. In your example, say that rule 2 paints a 2x2 stamp but to the left (because of the pivot). This means that content produced by rule 1 could be actually blocked while it's already evaluated.

[Gamer-XP]

Yes, it can override already processed data, but it will save performance because overridden tiles did not process all the rules yet + it should make high-placed Big Tile Rules have higher priority overall.

So, let's say you've processed 2 single tile rules. It created few tiles here and there. Then you've encountered a rule that will create 3x3 block around current tile. It will override already existing tiles on the top/left, and will remove this 3x3 block from further rule evaluation. I think, it will ignore this rule if there is already any tile in this 3x3 area, but may add an option to override existing ones.

[DavidHospital]

Yes, it can override already processed data, but it will save performance because overridden tiles did not process all the rules yet + it should make high-placed Big Tile Rules have higher priority overall.

So, let's say you've processed 2 single tile rules. It created few tiles here and there. Then you've encountered a rule that will create 3x3 block around current tile. It will override already existing tiles on the top/left, and will remove this 3x3 block from further rule evaluation. I think, it will ignore this rule if there is already any tile in this 3x3 area, but may add an option to override existing ones.

What happens if we have the following rules:

1. single tile rule, places a few here and there
2. 2x2 (pivot bottom right), overwrites some tiles from rule 1
3. Another 2x2 (pivot bottom right), overwrites some tiles from both rules 1 and 2

Here, rule 3 will cause some stamps created from rule 2 to be partially changed, resulting in some incomplete stamps.

I think maybe allowing an option for each rule to overwrite previous tiles this way could work. So if the only rules being overwritten are single tile rules, we can still apply those rules first if that is useful to someone.