Hello everybody!
I have recently started to make small game jam project with friends using Godot. I previously had some experiences with it, but only on solo dev project. I really like it. I recommended it, and we used it on several project with git the following way: we split our project in a lot of small scene to avoid conflict, and everybody works on their branch. We communicate to be sure nobody is working on the same scene.
Now we face problems that could mean the end of our godot usage as a team: After some commit (I’ll say the first one after a fetch), the uid of some random scene changes and will cause merge conflicts. It seems that there is no logic to it, and it leads to a lot of time lost, sometimes file corruption. The faulty commits are then extremely hard to track. Today we worked with godot 4.4 and it was even more painful. We lost a lot of our project.
I really want to continue to work with Godot, but I should say that my teammates were talking about learning other engine (and I want to be clear: the git conflict is our only issue; but we took half our coding time resolving conflict, reverting commit, cherry picking, etc. just so the master branch has something working on it)
If I have to choose between believing that our workflow sucks or that it is impossible to work with Godot in a team, I’m 99% on our skill issue. If you have any solution or advice, thank you! If you work on a team and you never had those kind of problem, that is also good to know!
Best
You must log in or register to comment.
There was a big change regarding UIDs in Godot 4.4.
You should have seen a warning popup about this when you first updated your project to 4.4. You would have been given the option to convert all files to the new UID format.
As far as I understand, this should have been done by one developer as the only change. An “upgrade to Godot 4.4” commit if you will. Then all other devs should have pulled that, then continued work.
Ideally this would be done on a branch to test the effect on the project. Engine updates should never be taken lightly during a project. This applies to any game engine.
To add to this, I work alone on my game currently, but often on two different machines.
I upgraded to Godot 4.4, did the auto convert thing for the new UIDs, pushed that change to git, pulled on my other machine, and I’ve had no issues.
I found this Reddit thread that seems to explain the cache and why the UID changes. The solution seems finnicky though. Just rebuild until they are synced? Thats gotta be complicated with multiple people.
Edit: reading that thread. It looks like this is new with the UIDs and the Godot team is still working it out. Seems really bad tbh. This might make me switch back to Godot 3.x of some kind for my development.
I think this is 4.4 specific, so you could just go back to 4.3 instead of all the way back to 3
Oh the first article I read mentioned UIDs being added in 4 and I just ran with it. Thank you for the info.
Are you committing the import
.importfiles? These contain the import settings for assets, as well as the uids the engine assigned to them.It seems that there is no logic to it, and it leads to a lot of time lost, sometimes file corruption.
I don’t have very much practical experience with Godot, but the jam project I did with a friend uid generating was never random. From what I remember, when changes or conflicts occurred, I was always able to understand why they occurred.
What do you mean by file corruption? On the text files? You mean unfeasible to resolve conflicts or actually corrupted - as in unreadable? I don’t see how the latter would be possible with Git.
Speaking more from my software dev background than actual Godot experience; Making sure to committing and pushing generated scenes and uids or any changes really early and often should mitigate conflicts. Of course that’s only a mitigation, not understanding or resolution though.
The uids’ re-generation might be faulty, as they’re new to 4.4.
In theory the problem can still arise without using uids - it certainly has for me in the past, working on a godot 4.2 project on 2 separate machines. Godot imported the same things twice, once independently on each machine, and so generated different ids for them. From what I can tell the biggest error/mistake on my part was opening the project in the godot editor before pulling the newest commits.
The best approach I’ve found so far has been to be very conscious about when a new scene is created, and to similarly be very mindful when merging git branches.
If a scene was added, but not its .uid file (or a resource but not its .uid or .import) then whoever pulls the code and then opens their 4.4 editor will generate new uids on their end. This generation probably updates the scattered .tscn files that participate in and/or use the newly added scene.
Sadly I don’t have an exact method or workflow to recommend beyond trying to do git pulls/fetches before opening the editor, especially when new scenes, nodes, or resources have been added to the project.
I thought the whole point of the new UID feature is 4.4 was to help with git workflows?
I think that’s the point of it. I also don’t think they’ve encountered every possible bug with it yet, so it might take a while before all the kinks get ironed out.
The big “win” that these uids seem to already bring is unicity of id for resources - the problems I’ve had in previous editions of Godot were of the form where an asset’s locally generated id doesn’t match up in the various scenes that use it.
