Large TileMapLayer nodes cause issues with merging git branches

Help Programming
,
1

Godot Version

4.5.1

Question

Hello!
I’ve just encountered a git (?) issue which (I assume) is caused by how Godot stores tilemap data (in one, long line). I have a 2D platformer game which uses a TileMapLayer as the base level environment. The TileMapLayer has tiles more or less contained within a rectangle area of 650x150 tiles.
We’ve not had any issues with it before, until today. Both me and a coworker made different changes to the scene which contains the TileMapLayer (I modified the original layer, she modified another layer that’s on top of the original) and when merging, there were merge conflicts. Our mergetool (kdiff3) crashed every time (on multiple machines) specifically when scrolling down to attempt to display the line that stores the TileMapLayer data. I tried to change the mergetool to vscode, but it didn’t even manage to open the merge conflict resolving view (even though it manages to open the individual files without any problem). This suggests that this isn’t a kdiff3 or vscode issue, but rather a git limitation? maybe git doesn’t like merging files which have lines that are hundreds of thousands of lines long? (While merging, the line containing TileMapLayer data was about 590 000 characters long.)

  1. I’m currently wondering whether it’s a git limitation or if Godot’s Tilemaps shouldn’t be used with such big maps? But it feels weird that 650x150 dimensions would be too much when TileMapLayers are supposed to be built for scale.

  2. if anyone has any ideas on what could be the problem here, I’d greatly appreciate it. I’m considering splitting up the TileMapLayer into several smaller layers, but the name suggests that they should be treated as “layers”, not sections. It doesn’t feel like the right solution

  3. There is always the possibility that some data in the file was somehow corrupted, but I doubt it because both pre-merge branches launch the scene without any problem.

Please let me know if I’m using TileMapLayer nodes incorrectly and I should split it into parts, or if it’s a git issue, or any other insight you might have.

2

Have you tried resolving the conflicts in VI or another text editor?

This really sounds like an issue with the diff tools you’re using.

If it were me, I’d accept changes from one that had fewer changes, and make the other changes again.

3

All the versions of the file (BASE, LOCAL and REMOTE) can be opened separately in Notepad++, kdiff3 and vscode, though kdiff3 and vscode slow down noticeably when I scroll down to the extremely long tile map data line.
When trying to solve merge conflicts, kdiff3 and vscode both fail to open their dedicated merge conflict resolving tools entirely. Notepad++ is not really a difftool, though it manages to open two files at once.
We’ve managed to fix that one particular conflict by hand, but kdiff3 has always been very helpful when solving conflicts, and those are likely to crop up more in this project, since it’s a TileMapLayer-based 2D platformer.

So you don’t think this could be caused by the TileMapLayer being too large? The size isn’t that big and being forced to split them up feels counter-intuitive to the design idea behind the node (scalability).

4

Most text editors are not designed to work well with extremely long lines. Yout tilemap layer is not too large for Godot, it just is too large for your text editors. So you need to find a merge tool that supports long lines.

You could also create a proposal to change the tilemap layer storage system to be more editor / merge tool friendly. Currently the data is stored in a single PackedByteArray. Maybe there could be a project or an editor setting that changes this for example so that every tilemap row is stored in a separate PackedByteArray. Or the data is stored in constant size chunks.

1 Like
5

Ok, well I’d recommend going with a command-line tool then like Emacs or VI. Also, you could run a git diff on the command line and get all the issues, make the decisions that way. Then edit the file and update it. Both options are in the merge file. Merge tools are nice, but not necessary to resolve a merge conflict.