portponky / better-terrain Goto Github PK

So I'm making a tile based game that features slopes. I need to be able to pick the slope I draw, but then have the surrounding square block tiles peer with it. This is of course impossible with the default terrain system since you need tiles that can peer with multiple other tiles using the same bits. With your addon it's a bit better- however, the only workflow I managed to come up with involves peering the blocks, then making a category containing all the slopes, blocks set to peer with it. This works, but I need to go into the default tilemap editor to paint my slopes, THEN go into your terrain editor and repaint the surrounding blocks to update them. And also the selected layer isn't synced between them so you gotta watch out for that.
What would be nice is a simple UI for painting individual tiles within a terrain, the way the default terrain system allows, or alternatively just a way to automatically update tiles according to the better terrain peering rules perhaps? The second option would be nice because then I could retain all the cool features from the default tilemap editor, like patterns and selecting multiple tiles to place at once which I don't think the default terrain system can even do since it presents the tiles in a linear list.

Does this sound feasible?

I've created a tileset using shaders but I can't really see what I'm doing in the terrain tab

Thanks for making such a useful plugin!

I'm currently painting the rules for a tileset using this fantastic plugin (thank you!)

I keep erasing & redrawing, or painting over, my test scene, to ensure that my changes work together as expected in a real layout. It would be immensely useful to have a button that re-paints the current tilemap, keeping the assigned terrains, using the latest tileset data.

There is no Contributors section in readme file .
As we know Contributions are what make the open-source community such an amazing place to learn, inspire, and create.
The Contributors section in a README.md file is important as it acknowledges and gives credit to those who have contributed to a project, fosters community and collaboration, adds transparency and accountability, and helps document the project's history for current and future maintainers. It also serves as a form of recognition, motivating contributors to continue their efforts.

Am not quite sure if this is an actual problem with Better Terrain or with my code!
I really enjoy Better Terrain, it already helped me quite a lot and is imo way better than the default that Godot has. Thank you really much for the plugin!

So what happens is I create a noise filter, loop through two FORs for X and Y coordinates, calculate if they are too far away from my radius, and if not, check which noise I have on this Coord, and set a tile accordingly.

That leads to me being able to create circular (or which ever shape I want) islands with different terrains.
To make it more performant I only update the layers when the whole island is calculated.
I have overall ~6.400 - 14.400 Tiles I want to set and after that update.

It looks a bit like that:

• Start a thread to calculate the island size and which tiles to place
• set the tiles via better_terrain.set_cells on the main thread
• add the tiles that just were set to the update queue as a batch
• update the tile batch on a new thread

Because I use the same array and layer_id for update_terrain_cells as I do for set_cells, I am pretty sure that the tile exists.

When I open up a thread for each layer at once with "update_surrounding_cells" = false OR true (both cases) it fails:

It is btw not the same layer. Sometimes it is the third, sometimes the seventh, ... that doesn't seem to be the problem.

When I open up a thread for each layer after each other with "updating_surrounding_cells" = false it fails:

When I open up a thread for each layer after each other with "updating_surrounding_cells" = true it succeeds:

How I start the threads:

How I kill the threads:

I just change
if !tile_batches_to_update.is_empty() && !tile_batches_updating:
to
if !tile_batches_to_update.is_empty():
to start multiple threads at once

It could totally be that my thread work is crap and that this causes the error, but I don't think that it should crash at all, even if there is a problem.

I think there might be a slight issue with how you set up the plugin download through the Godot AssetLib tab. As you can see from the screenshot, it tries to add a license and readme to my project's root res directory, instead of in the addons folder.

One major limitation for me in this version is being able to have cells where the central bit is missing, which allows connection to empty terrain, creating necessary walls and corners outside of the active tile. This is currently possible in Godot 4:

In this example I am connecting vertices / matching corners, but this feature would ideally also feature when matching tiles.

My usage of this feature would be to separate different terrain types onto different layers, but this requires each terrain type to autotile within empty cells as if it had a different terrain adjacent to it.

Would you consider adding this?

I'm spending a lot of time using this plugin. One thing that would make the work flow much better is to have the Terrain section remember if it was the last used section and open automatically, or some other suggestions:

1. Make it shortcut keyable, so when you click on a TileMap node you can shortcut key to open the Terrain tab. Not sure if this is possible.
2. Make it to where when you click on a TileMap node it auto remembers where you were and go to Terrain tab if you were on it.
3. Maybe move the Terrain from your plugin to be nested inside the TileMap under the sub BetterTerrain tab or something, that way it remembers what tab you were on with the built in Godot functionality. The regular TileMap does this with it's tabs (Tiles, Patterns, Terrains) and it makes it really nice for back and forth workflow. I know clicking on a TileMap node goes to the TileMap section no matter what, so I'm not sure how this would be possible.... but if it is I figured I wanted to bring this up.

The above ideas were just my initial thoughts, there could be a better way I'm sure. Thanks for reading and the plugin!

This is a feature when placing tiles normally through the tilemap tab at the bottom, and it would be great if I could do this too in the terrain tab to prevent me from placing tiles on the incorrect layers.

As a side note, have you considered adding this plugin to the Godot asset library and adding a version number? Would make it much easier to manage updates. Thanks!

I tried loading it in a project already in progress, along with attempting to load it in a fresh one. In both instances it results in the picture above. It's throwing "not declared" every time it calls for BetterTerrain.

The first instance of the error is as you can see line 63 of TerrainProperties.gd.

The visually identifiable issues these errors cause are that when selecting the tilemap section the buttons your addon are supposed to provide do not appear, and as far as I can tell there are no changes to the terrain system from normal godot functionality.

I'm going to do a little bug hunting to see if I (even with my limited skill) can figure out a solution

Adding the ability to set a preview icon for terrain would greatly enhance the user experience.
This includes Adding a button at the toolbar to enter Select Icon mode to set the preview icon for terrain and show an icon preview in the Tree.
A rough prototype: (there is no new button in the toolbar but you got my point)

Okay so with that other thing taken care of, I was wondering if there were any plans for copying terrain setups between tilesets. I have a pipeline to generate these things with the same layout every time and it would be nice not to need to manually set up the complicated peering bit config for every individual set.

Can it be done?

Hi,

Thanks for making this plugin, it's quite amazing.

I noticed that inner corner tiles (e.g. L shape) with simpler tilesets (e.g. 3x3 set of tiles only) don't tile correctly. I see that this is the case in your intro video, too, with your 4x4 platformer tiles.

Is there an easy way to make corner tiles draw correctly, instead of using the center/fill tile?

Hi,

I've spent some of today playing around with this plugin in the hope it can fill the gap left by the built-in terrain system.

I've ran into a problem where the terrains aren't persisted when I restart Godot. I think I've identified the issue as being that I'm using a custom TileMap which is causing the terrains not to be saved.

There are no errors messages from what I can tell.

In a map generation project (using cellular automata and some ruling) I'm trying to generate a map using 13 possible tiles instead of a full 64 set.

The tileset I'm using for this is free to use:

and I configured it with 3x3 matching and only a subset of it in the terrain, as follows:

When generating, I'm using BetterTerrain.set_cells then BetterTerrain.update_terrain_cells in order to apply the generated terrain to my tilemap.

First of all, it really works way better than the builtin system, which was struggling to fill some basic square shapes.

The result, however, contains some unmatched cells (of course, I have 13 possibilities but the terrain has a lot of different connections) and it made me wonder if it'd be possible for thie addon to have a method that cleans up tiles that do not perfectly match.

Taking this example:

it'd remove the "lonely" tile that's on top of the uniform "blob" below it.

Cleaning things up before sending it to the terrain is quite hard because it means having to implement connection checks which is already done in your addon, and I was thinking maybe this could be done by the addon itself.

Is there any way to set wildcards it's one of my largest gripes with godot 4.0. For example I want the terrain to match with any tile regardless of type.

I'm getting warnings for BetterTerrain.cs CS8632: The annotation for nullable reference types should only be used in code within a '#nullable' annotations context.

because you've used ? on things that are already nullable by default like Array<int>? categories = null where Array<int> categories = null works fine.

this technically is a thing you can do with Nullable contexts to make these reference types not nullable by default but there's none in the file.

I'm just wondering if I'm missing any context before just removing the ? from the reference types or if maybe you just weren't familiar with these types already being nullable by default and the ? being unnecessary.

i notice my probability tiles are always in the same spot. i figured they were rolled sometime and was wondering if we can get a way to reset the seed?

After the most recent youtube video, decided to upgrade my Better-Terrain install, but now I can't even get the add-on to load properly.

It appears that Godot thinks all the tscn files are "corrupt" which leads to dock being null and crashes the whole thing.

Here are all the errors:

  Unable to open file: res://.godot/imported/MatchTiles.svg-38111e21a893bd8f161311f0d1968a40.editor.ctex.
  Failed loading resource: res://.godot/imported/MatchTiles.svg-38111e21a893bd8f161311f0d1968a40.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/MatchTiles.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/MatchVertices.svg-288fe47ee1089920379407d6abf1a06c.editor.ctex.
  Failed loading resource: res://.godot/imported/MatchVertices.svg-288fe47ee1089920379407d6abf1a06c.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/MatchVertices.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/NonModifying.svg-4d16d471be4a8f1d3ba0c013ff629ee1.editor.ctex.
  Failed loading resource: res://.godot/imported/NonModifying.svg-4d16d471be4a8f1d3ba0c013ff629ee1.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/NonModifying.svg. Make sure resources have been imported by opening the project in the editor at least once.
  scene/resources/resource_format_text.cpp:284 - res://addons/better-terrain/editor/TerrainProperties.tscn:60 - Parse Error: 
  Failed loading resource: res://addons/better-terrain/editor/TerrainProperties.tscn. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/Decoration.svg-03773e83cc849c7744ecf3d36eee0072.editor.ctex.
  Failed loading resource: res://.godot/imported/Decoration.svg-03773e83cc849c7744ecf3d36eee0072.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/Decoration.svg. Make sure resources have been imported by opening the project in the editor at least once.
  scene/resources/resource_format_text.cpp:284 - res://addons/better-terrain/editor/TerrainEntry.tscn:82 - Parse Error: 
  Failed loading resource: res://addons/better-terrain/editor/TerrainEntry.tscn. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/EditType.svg-e7b3005c6a8f21d5102295c55b564ad1.editor.ctex.
  Failed loading resource: res://.godot/imported/EditType.svg-e7b3005c6a8f21d5102295c55b564ad1.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/EditType.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/Replace.svg-7654df79fd42fc27133e4d3f81a4d56b.editor.ctex.
  Failed loading resource: res://.godot/imported/Replace.svg-7654df79fd42fc27133e4d3f81a4d56b.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/Replace.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/EditTerrain.svg-f7ee950d68a391de33e4e8ddd76bf2ac.editor.ctex.
  Failed loading resource: res://.godot/imported/EditTerrain.svg-f7ee950d68a391de33e4e8ddd76bf2ac.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/EditTerrain.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/Warning.svg-7bb0ec60ff2da2c7ebdba79b0dcdd006.editor.ctex.
  Failed loading resource: res://.godot/imported/Warning.svg-7bb0ec60ff2da2c7ebdba79b0dcdd006.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/Warning.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/ShuffleRandom.svg-15ee49f7a06c55a1e95e1ed056732dc5.editor.ctex.
  Failed loading resource: res://.godot/imported/ShuffleRandom.svg-15ee49f7a06c55a1e95e1ed056732dc5.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/ShuffleRandom.svg. Make sure resources have been imported by opening the project in the editor at least once.
  scene/resources/resource_format_text.cpp:284 - res://addons/better-terrain/editor/Dock.tscn:100 - Parse Error: 
  Failed loading resource: res://addons/better-terrain/editor/Dock.tscn. Make sure resources have been imported by opening the project in the editor at least once.
Add Autoload
  scene/resources/packed_scene.cpp:141 - Condition "nc == 0" is true. Returning: nullptr
  res://addons/better-terrain/TerrainPlugin.gd:12 - Invalid get index 'update_overlay' (on base: 'null instance').
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/Decoration.svg-03773e83cc849c7744ecf3d36eee0072.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/EditTerrain.svg-f7ee950d68a391de33e4e8ddd76bf2ac.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/EditType.svg-e7b3005c6a8f21d5102295c55b564ad1.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/MatchTiles.svg-38111e21a893bd8f161311f0d1968a40.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/MatchVertices.svg-288fe47ee1089920379407d6abf1a06c.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/NonModifying.svg-4d16d471be4a8f1d3ba0c013ff629ee1.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/Replace.svg-7654df79fd42fc27133e4d3f81a4d56b.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/ShuffleRandom.svg-15ee49f7a06c55a1e95e1ed056732dc5.editor.meta'
  Missing required editor-specific import metadata for a texture (please reimport it using the 'Import' tab): 'res://.godot/imported/Warning.svg-7bb0ec60ff2da2c7ebdba79b0dcdd006.editor.meta'
  :12 - Unknown identifier in expression: 'u_windowSize'.
  Shader compilation failed.
  ./servers/rendering/renderer_rd/shader_rd.h:165 - Condition "!version" is true. Returning: RID()
  ./servers/rendering/renderer_rd/shader_rd.h:165 - Condition "!version" is true. Returning: RID()
  ./servers/rendering/renderer_rd/shader_rd.h:165 - Condition "!version" is true. Returning: RID()
  ./servers/rendering/renderer_rd/shader_rd.h:165 - Condition "!version" is true. Returning: RID()
  Unable to open file: res://.godot/imported/Decoration.svg-03773e83cc849c7744ecf3d36eee0072.editor.ctex.
  Failed loading resource: res://.godot/imported/Decoration.svg-03773e83cc849c7744ecf3d36eee0072.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/Decoration.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/EditTerrain.svg-f7ee950d68a391de33e4e8ddd76bf2ac.editor.ctex.
  Failed loading resource: res://.godot/imported/EditTerrain.svg-f7ee950d68a391de33e4e8ddd76bf2ac.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/EditTerrain.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/EditType.svg-e7b3005c6a8f21d5102295c55b564ad1.editor.ctex.
  Failed loading resource: res://.godot/imported/EditType.svg-e7b3005c6a8f21d5102295c55b564ad1.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/EditType.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/MatchTiles.svg-38111e21a893bd8f161311f0d1968a40.editor.ctex.
  Failed loading resource: res://.godot/imported/MatchTiles.svg-38111e21a893bd8f161311f0d1968a40.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/MatchTiles.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/MatchVertices.svg-288fe47ee1089920379407d6abf1a06c.editor.ctex.
  Failed loading resource: res://.godot/imported/MatchVertices.svg-288fe47ee1089920379407d6abf1a06c.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/MatchVertices.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/NonModifying.svg-4d16d471be4a8f1d3ba0c013ff629ee1.editor.ctex.
  Failed loading resource: res://.godot/imported/NonModifying.svg-4d16d471be4a8f1d3ba0c013ff629ee1.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/NonModifying.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/Replace.svg-7654df79fd42fc27133e4d3f81a4d56b.editor.ctex.
  Failed loading resource: res://.godot/imported/Replace.svg-7654df79fd42fc27133e4d3f81a4d56b.editor.ctex. Make sure resources have been imported by opening the project in the editor at least once.
  Failed loading resource: res://addons/better-terrain/icons/Replace.svg. Make sure resources have been imported by opening the project in the editor at least once.
  Unable to open file: res://.godot/imported/ShuffleRandom.svg-15ee49f7a06c55a1e95e1ed056732dc5.editor.ctex.```

It will be great if we can hold mouse middle key to pan in the terrain panel, just like in the default TileSet and TileMap panels.

Now that godotengine/godot#80144 is merged, I think it would be a perfect time to make use of this feature in Better Terrain to introduce automatically flipped/rotated tile alternatives.

I wanted to bring this up as an issue first to start a discussion about it, because I think you'd have a better idea of how the implementation would work.

Here's the problem I'm trying to solve.
I have a basic tileset with 48 tiles like so:

When painting tiles in the game, I want to reduce obvious texture repetition as much as possible. For this design, every angle is uniform (top-facing tiles look no different than bottom-facing tiles, etc.). I can utilize this aspect of the design to very easily make alternative sections by simply rotating the individual tiles in the base set 3 times:

This gives a lot more variation without any more work. (i could do this another 4 times by flipping them, but it's a lot more obvious seeing two flipped tiles next to each other than two rotated tiles near each other.)

So I have a tileset setup like this (with duplicates for background layers):

This works great, but it feels a little unnecessary, and also makes the plugin a lot slower.

I've been thinking about a better way to do this for a while, and I think this would be ideal.

My idea is this: auto-transformation options.
Terrain tiles can optionally have auto-transformation enabled for them. This would create duplicate tile entries in the terrain for each transformation, and also transform their peering bits in the same way.

I have two possible implementation ideas:

1. Auto-transformation options per terrain
In the terrain options will be a new list of toggles:

• rotate 90
• rotate 180
• flip horizontally
• flip vertically

With any of these toggles enabled, the terrain will effectively duplicate its existing tiles with the respective transformations applied as part of the new set of tiles for the terrain. So, every tile will have the same auto-transformations.

2. Auto-transformation options per tile
A new “view” would be added to the dock, alternative to the “peering bit” view.
In this view, hovering over a tile will show a grid of these same options as icons that you can toggle to specify which transformations are enabled for it:

(thinking about it more, probably better would be a painting mode where these 4 options are togglable in the toolbar and you paint on tiles to apply that option set)

Option 2 gives more control (and is the one I think I prefer), but its results could still be handled with option 1 by creating multiple terrains for each specific transformation set needed. (My specific case could be handled with option 1, but I would have to move some of the additional tiles out)

Now when drawing tiles, it will include (for instance) rotated tiles from other sections of the tileset in the placement choices. So in my example I could replace all 4 duplicate sections with a single section with the "rotate 90" option enabled.

This would also allow a full tileset to be extremely simple with only 6 tiles:

to allow painting any of the basic 16:

Handling the flipping/rotation of the sprite, collider, occlusion, etc. is already handled by the linked PR. The only thing that would need to be handled here is calculating the resulting peering bit transformations. The area I'm least confident in with this implementation is how the duplicate tile data should be handled; when should it be created, where it would sit in the terrain data, how it integrates with the tile picking functions.

Any input would be appreciated! Thanks :)

This, basically:

Not a biggie but it's quite easy to do by accident. I tried some stuff to fix it, but couldn't quite get it to behave.

Is there a way to detect whether or not a decoration has been placed? For example:

1. Given a tree_base tile and a decoration tile that represents the tree-top, peered to N of tree_base
2. Randomly drawing tree_base tiles (programmatically), which also decorates them
3. Randomly drawing other tiles, like rock, after first checking that neither a tile nor a decoration is in the target cell

It seems like get_cell returns -1 for decorations, as if they were empty. Is there an alternative way to query the state of the cell that would disambiguate between "empty" and "decorated?"

	public override void _Process(double delta)
	{
		if ((bool)_betterTerrain.Call("is_terrain_changeset_ready", _tileChangeSet))
		{
			_betterTerrain.Call("apply_terrain_changeset", _tileChangeSet);
			_tileChangeSet.Clear();
		}
	}

When using changesets I get this error output to the console thousands of times:

E 0:00:20:0605   _notification: This function in this node (/root/Game/GrasslandTerrain) can only be accessed from the main thread. Use call_deferred() instead.
  <C++ Error>    Condition "is_inside_tree() && !is_current_thread_safe_for_nodes()" is true.
  <C++ Source>   scene/main/canvas_item.cpp:280 @ _notification()

I might simply be missing something, but it would be nice if the terrain drawing tools had shortcuts that mirrored the default TileMap ones ( Draw tool - D / Line tool - L / Rect tool - R / Bucket tool - B )

A Picker functionality would also be really useful, in the default TileMap it's P or hold Ctrl, in this case it'd select the terrain type the selected tile belongs to

Dude. Thank you so much 👍 It fixed my procedural generation and it works literally 10x faster than default. From 15000ms to 1519 ms generating my 250x250 map. I don't understand why the team doesn't integrate something like this into the core. Thanks again!

First of all, I'd like to thank you for the awesome plugin! This is exactly how I expected the terrain tiling in Godot 4 to work :)

I noticed something weird. In my setup I have two terrain types: grass and water.

The terrain has a rectangular lake, inside a large patch of grass:

The strange thing is that the tiles near the corners (marked with the red arrows) will randomly pick between a straight transition piece, or a corner piece. When filling the lake repeatedly with "shuffle" enabled, I get different arrangements of these tiles. The rest of the tiles stay rock solid, even the actual corner pieces.

This is my terrain setup:
Connection rules for grass:

Connection rules for water:

From the connection rules I would assume that the only valid pieces for near the corners, would be the straight transition pieces.
Am I misunderstanding how the connection rules function? Or is there a bug in this specific situation.

Godot version: v4.2.1
Plugin version: v1.0

EDIT

As an experiment, I changed the connection rules to the following:

Now the lake does work, but it seems to get confused at the ends of this T shaped water section. It always fills those with full land, while according to the connections I would assume the straight transition pieces fit perfectly.

Thanks again for the great work!

I've been looking at implementing terrain grouping, and I have figured out a way to implement it whilst at the same time improving performance across the board. This will be my next feature, and I would like to get it done before Godot 4.0 releases, as it will likely be a breaking change.

In general, I want terrain types to belong to a category (or multiple categories), and then be able to connect to other terrains of those categories. For example, if you have different types of ground - sand, dirt and paved - you can give them all the same category and set up their peering bits to connect to their category. That's easier than setting up every combination of connections between them.

At the same time, I want to be able to support the terrain's uniqueness, so if there a specific special connection, that can be supported. In the same example, if you have water tiles that can connect with sand but not dirt/paved, then that should still be supported.

There are a number of ways that groups or categories could be implemented. For example:

Perhaps it could be an extra property on the terrain which allows it to appear as any other type of terrain, or a selection of other types. This is the most flexible (maybe overly so) but a poor UI.

Another option which is more clear and intuitive is to arrange terrain types in a hierarchy. This is a slightly less flexible, but very easy to understand. This is probably what I will go with unless there is a strong reason to do something different.

If you have any feedback about this, feel free to comment.

This is an issue to discuss the design of decoration tiles, as based on @torcado194 's PR implementation.

Here are two terrains with the empty cells marked.

There cells in particular interest me, as they are common to different terrains. This situation is very simplified, but the general principle can show up in any place and with multiple terrains (up to 8, in a very contrived way). A more classic example would be a fringe around a terrain type.

I like the idea of having a specific type of terrain to act in-place of empty tiles. The built-in system of having optional center bits is very, very confusing and does not appear to give a clear functional advantage.

Having multiple different decoration-type terrains does not appear to have a strong reason. Why make 2 types instead of 1? The only reason that stands out is to categorize different types of decoration and apply them to different terrain types as needed. However, Better Terrain already has a system for categorizing terrain (category types), so this advantage isn't clear cut to me.

Here's my current idea for how decorations could work:

Every terrain has a built-in 'decoration' type, which you can't change. It sits first in the list (or last?). You can't make more decoration types, this is just a special built-in type.

The decoration type acts exactly like a 'match tiles' terrain, but is considered equivalent to empty tiles. You can assign tiles to be decoration, and then set up their peering bits appropriately. You can't use the decoration type as a peering type (anywhere). For each decoration tile, you should give it peering bits for other terrains/categories to determine how it will appear.

This would keep all decorations unified (as all decorations are equivalent in terms of function), and visually/logically put them in one place for the user. It would also be a reversal of torcado's design, instead of assigning decorations to a terrain, you assign terrain (peering) to the decorations. The value there is that decorations can function between multiple terrain.

I am keen to get feedback on this. I am being cautious because once this is implemented and merged, the behaviour is locked in. Let me know what you think.

I set the probability of a tile to 0.0 in the tileset editor, but it continues to appear in the tilemap.

In the image below you see the middle source is unchecked. I can use the selection tool on tiles from the top source just fine, but when I try to use it on the bottom source's tiles I don't see any blue outline. If I then re-check the middle source I see the selection which I had tried to make on the bottom source was applied to the middle source instead even though it was unchecked.

Thanks fo what looks like a great terrain plugin.

Following the README and your YouTube videos I believe I should be able to paint using a category which contains one or more "Matching Tiles" terrains, however when I try to paint with it nothing happens and the tiles remain blank. There are no apparent errors to explain this either.

It works fine if I paint the walls and roof terrains indepentently but not if I use the category terrain.

Am I doing something wrong?

First of all, just want to say that I really appreciate the plugin and I'm pretty certain that I am not understanding tilemaps and / or terrain functionality properly but just wanted to check in since googling did not seem to yield much (at least not the keywords I searched).

I am working on procedurally generating a world. The basic landscape (ocean, some biomes) generate well enough and quite fast I would say. 500x300 2D map takes maybe a couple seconds with my machine.

My issue: I am trying to eventually generate some random cities but currently working on setting up some houses with the terrain functionality for autotiling. Currently, I seem to either have no door, or have multiple doors generated. Sometimes only 1 door, but I want to force it to always have 1 door:

Like I said before, I am fairly certain that the issue is probably how I am setting up the terrain logic for the door, but I cannot figure out. Would I need to modify a setting in a menu somewhere? Is this functionality available?

Follow-up question, in the image, you see a house with a massive roof, could I do some configuring in the tile Terrain to make it so the house would have a higher wall and a shorter, "more normal" roof?

There are some typos in the README file which need to be fixed, Kindly assign me this issue so that I can fix them.

Hi, I just found this plugin, and have been enjoying it quite a bit, but for my current project i'm using tiles that are 8x8px, and they don't look particularly good as icons due to how blurry they are. Considering the fact that you can set icons to whatever you want, and not just tiles, it might be good as an option

Although honestly, this might be more of a bug report? the tiles in the actual window look sharp even at different sizes, its just the actual terrain categories themselves that do not

When drawing large amounts of tiles you will have a noticeable performance impact, my solution for this was to batch draws in small chunks at a time. This only partially solves the problem however, with this solution framerates will stay high but you will have stuttering.

The best solution I can find to this is to use call_deferred for apply_terrain_changeset. The problem with this is that there is currently no way to know when apply_terrain_changeset is done with the dictionary reference you pass it, thus preventing you from clearing the dictionary and loading up the next changeset.

Maybe this is to specific of a use case to be implemented, but figured I'd through up the suggestion.