Godot-proposals: Randomize resource IDs in scene files (GUID)

[ignaloidas]

Describe the project you are working on:
Several small games with multiple developers.
Describe the problem or limitation you are having in your project:
Quite often several developers add something to a scene, and it is annoying to merge the changes since, for example, if an external resource was added in both patches, it would have the same resource ID, thus requiring to go through every mention of that ID and decide which one it should be.
Describe the feature / enhancement and how it helps to overcome the problem or limitation:
We could randomize resource IDs in the tscn format. This would allow for easier merges, often fully automatic. The only problem could be when resource is deleted in one patch and used in the other one, but this can already happen.
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Instead of setting increasing resource IDs when saving, set random ones for new resources.
If this enhancement will not be used often, can it be worked around with a few lines of script?:
This would be used often. Technically one could write a script that would randomize resource IDs before commiting, but that would be hacky and prone to bugs.
Is there a reason why this should be core and not an add-on in the asset library?:
Easier to do in core and affects most developers.

[clayjohn]

This wouldn't eliminate the issue though. Consider the issue where two developers both add an external resource to a scene and the RNG turns up the same number. Sure, it would be more rare, but the problem is still there. And in this case it would be more troublesome as developers would be relying on the randomized values.

[ignaloidas]

Using long enough numbers the chances of it happening would come down to nearly zero. We could additionally incorporate the time something was created, or the MAC of the machine like various UUID versions does.

[Calinou]

See also https://github.com/godotengine/godot/issues/15673 and https://github.com/godotengine/godot/issues/22226.

[ignaloidas]

godotengine/godot#22324 as well.

[RabbitB]

@ignaloidas Using 64-bit GUIDs, it's very likely that no Godot user anywhere would ever encounter a collision. If we wanted to be absolutely sure, we could do like MS and use a 128 bit GUID as is available in .NET.

At 128 bits, MS docs say the GUIDs are intended to be use as public identifiers across open networks and the entire web, and even then, across the entire internet, it's likely we'll see the heat-death of the universe before the same GUID was ever generated twice.

[Wavesonics]

@RabbitB I worked at a AAA studio w\ a very large game using hashes of object names as GUIDs, and they hit collisions now and then :P

That being said, I think it's still be a good solution. It'd make the chance very very small.

[RabbitB]

@Wavesonics Hashes are very different from pure GUIDs, although hashes are often used interchangeably.

Anytime you're taking a larger number of bits and hashing them to fit into a smaller number of bits, you're going to run into the possibility of collisions. GUIDs as generated by .NET aren't hashes, but pure random numbers that have no relation to the objects you want to refer to. They're generated independently from the data and simply used as identifiers.

[sekhat]

@RabbitB @Wavesonics Guid's also do have a chance of collisions. But every once in a blue moon is much better than every time two developers make changes to resources in a scene in different branches.

[Wavesonics]

@sekhat yes, totally agree. I would love to see this proposal implemented.

[lucaspcamargo]

This is a big problem for us at the studio I work in. Every other change, every other merge, becomes a painstaking process of looking into the text files and combing through the mess.
It'd be great to see this implemented for 4.0 or even 3.x

[Calinou]

@lucaspcamargo Given how this change will most likely break compatibility, I doubt it can be implemented in 3.2.x.

[LikeLakers2]

@Calinou I'm curious, how do you see it breaking compatibility? The way I understood IDs in TSCN files, it shouldn't matter what type of ID (or even what the ID is) a resource has while loading, just so long as the ID is the same everywhere that the resource is wanted.

[lucaspcamargo]

Yes, I thought of something along these lines: Imagine if the IDs began to be treated as hex numbers, internally stored in an int64_t. Since the IDs are local to the file, I can't see anything breaking unless I'm missing something. Of course, they would have to be treated as keys to a dictionary instead of indexes of an array.

[cgbeutler]

@Wavesonics for stuff done in parallel, it can help to use a GUID implementation that uses the machine name hashed with the creation time to randomize. This reduces collisions. Maybe that would be good here...?

[AnomalRoil]

This would be really useful for game jams where we work in a team in a very short period of time since conflicts arise all the time otherwise.

Edit: this is providing a use-case to motivate the proposal... Unless I'm missing why such proposals exists, it seems on-topic if you ask me...

[Calinou]

@AnomalRoil Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.