Terrains don't always save/persist

[thommor]

trafficstars

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.

[Portponky]

There have been a few reports of this behavior, but I have been unable to reproduce it. The terrain data is saved as metadata in the tileset and tiledata classes, so it is handled by the engine entirely, and any failure to save/load the metadata is likely to be an engine bug. In any case, I haven't experimented too much with custom tilemaps, so I will have a look at this next time I am updating the plugin.

[thommor]

If I get change I'll see if I can pin down the issue

[jpojecp]

I’ve also been experiencing terrain data not applying/not persisting on project reload. I already sent a video of it happening on discord, but here’s some other things I’ve noticed:

• Godot 4.0.2 on Windows 11
• I don’t have a custom tilemap node (assuming that means a script that inherits from tilemap). I’m editing a saved tileset resource directly, but I think it also happens when opening a tileset tied to a tilemap.
• It’s immediately a problem - I don’t need to reload the project, there’s just an immediate desyc between what the Terrains tab shows and what actually happens.
• It only happens once. The second time I try to edit the same data, it works.
• However, if I try to edit two types of data, only the first edit goes through. Ex: adding a terrain, then adding tiles to the terrain. Or changing the bitmask of one terrain, then changing the bitmask of a second terrain.
• After reloading the project, if the edit actually went through, the titlebar will show “(*) scenename.tscn” as though it already has changes that need to be saved, regardless of whether I saved before reloading.

[thommor]

Maybe this is a bigger issue than I thought.

I assumed it was the custom TileMap because if I used a normal TileMap with a new TileSet it persisted as expected.

• I have also experienced this on a Mac as well as Windows 11 (I develop on both)
• I assumed it was the custom TileMap because if I used a normal TileMap with a new TileSet it persisted as expected, maybe I just got lucky with it actually saving.
• I have also noticed it looking like there are changes to be saved upon opening the project but hadn't attributed that to better-terrains but can't say I'd noticed it before.

[ALBtheALBatross]

It doesn't save again after the first save, so my ugly solution currently is whenever I want to make a change to the terrain, I quit the editor and restart, then I can make changes that persist again.... until it's saved again, then repeat.

I'm on godot 4.0.3 and the behavior is the same on both my windows 11 and 10 machines

[univeous]

For me this happens with tilesets saved on disk as a resource. The 'built-in' tilesets work fine, but the saved tileset's metadata will not save unless I click them in the inspector. I can reproduce this issue consistently.

[Portponky]

I had some time to look at this, and it appears to be a Godot bug. If I get time to make a small compilable example, I'll open a bug report.

Workaround, after editing the terrain use the drop down and select 'Save' to write the altered tileset to disk:

[TheKassaK]

This explains the strange bugs I had.

Thanks @Portponky, with your tips its ok

[alijaya]

Hello, I've encountered this bug also, yes I think the cause is the TileSet is not saved properly when you set the meta, so I added this line, and it seems fixed the bug

func _set_terrain_meta(ts: TileSet, meta : Dictionary) -> void:
	ts.set_meta(TERRAIN_META, meta)
	if Engine.is_editor_hint() and ts.resource_path: ResourceSaver.save(ts) # force save the resource when it's in editor

[Portponky]

That's super interesting. I don't want to force save, because the user may want to revert the file (or be prompted to save). Perhaps there is a way to force the resource to be marked as changed? I've seen godot devs suggest a no-op undo action (here: https://github.com/godotengine/godot-proposals/issues/2153#issuecomment-1159542346) though that doesn't seem perfect as the user could undo it.

[tbrown19]

Just wanted to report i am also facing this but the above manual save helped, but it was very confusing at first what was happening. Noticed it that whenever i am trying to update the terrains they dont save unless i do the manual click save on the tileset. I thought it used to work properly when i first brought the tileset in, not sure what changed.

[gatomesa]

I think it would be good to mention this bug (as well as the workaround) in the documentation, as it can really throw someone for a loop if their project happens to be affected.

[Portponky]

I think I have a solution for this, but I can't reproduce it reliably to check.

I have put the fix on the branch fix-terrain-changes-getting-lost which is a branch off main (currently 4.2 based, so targeting the TileMap node rather than TileMapLayer). If someone who can reproduce this reliably is able to test this and report back, we can hopefully close this rather annoying bug.

[vabrador]

I reproduced the changes in this commit (https://github.com/Portponky/better-terrain/compare/main...fix-terrain-changes-getting-lost) on my local copy of the 4.3 branch version of Better Terrain (on top of commit 7292f5c8) and it has fixed the issue for me.

I'm not sure what happened that started the problem, although there was some error spam I had to fix right before the issue started occurring related to the Array[Vector2i] return type in BetterTerrainData.gd: This error started when I tried to paint a vertex-based terrain on 4.3, but tile-map-layers HEAD is 3 months old so it's likely this has already been fixed elsewhere.

I do find it suspicious that the saving issue started happening after an error was raised while editing terrain. Maybe Godot's behavior for detecting resource-changes, changes, if a plugin's _edit() or _forward_canvas_gui_input() flow raises an error?

Sorry I can't report a reliable reproduction of the issue, but I can at least confirm the expected fix branch works for 4.3.

[Portponky]

Thanks, that sounds good. I'll merge it back soon and that should fix this issue.

[Portponky]

Fixed by #99