Help resolving Git merge issue due to duplicated SpriteImageId

It looks like this is hard to fix, so we reverted before the change on one side and re-implemented. Is there a possibility that C3 could handle this case (when two contributors create new sprites w/ different animations, no conflicting names in two separate repo and can merge even if there are matching spriteImageIds?)

Would it be similar to what is done with UIDs in C2/C3:

Construct 2 assigns UIDs to objects in the editor. These are saved in the layout XML files for each instance. Construct 2 will assign a newly placed instance the lowest unused UID. This means if two clients who both place a new instance then merge their projects, it's possible the XML file uses the same UID for two objects. Luckily Construct 2 handles this gracefully: if it reads a project which specifies two objects with the same UID, it will simply assign one of the objects a different UID. This will show up next time you commit - you might notice an object you didn't think you modified got a new UID, but it's just Construct 2 making sure that it really is a unique ID!

I don't think Construct can handle this case, you're basically corrupting a project and then asking Construct to understand it anyway.

Source control ought to stop you before you make conflicting changes. There are special mechanisms for handling conflicts. And you're right that the easiest way to solve them is to revert back to before the conflict, update, and try again.

Thanks for looking at it Ashley.

Unfortunately, my understanding is that source control cannot detect this case, because the changes that cause an issue for C3 are happening in different files. Git/SVN cannot detect this as an issue.

For example, in two different branches, one user adds Sprite1 w/ 1 frame, another user adds Sprite2 w/ 1 frame. One user pushes to repo, then the second user pushes and tries to merge. Git will not detect any merge issues.

The *.c3proj file will have non-conflicting changes (two objects added with different names.)

Two json object files well be created w/ different names one per user/branch: Sprite1.json and Sprite2.json. So git will not detect a conflict.

Two animation images will be created with different names: Sprite1-*.png and Sprite2-*.png. So Git will not detect any conflict.

However, in some cases, the Sprite1.json and the Sprite2.json will use the same imageSpriteId for the animation frame. This will cause an error in C3 when loading, but git cannot detect it.

Since if it seems there cannot be a change to C3 like what is done for UID, the conflict detection I am thinking about is to add CI to our git repo that goes through the branch of the PR and detects for duplicated imageSpriteIds between different object json files. We could at least detect conflicts, though I don't think there is anything we can do about it, except reverting/refusing the PR. I don't know of a fix (e.g. change a imageSpriteId manually seems like a very bad idea, since it must be included somewhere else also (in png meta data?)). Thoughts on CI detecting this type of issue would be appreciated.

Of course, we will also add some 'rules' to our team workflow. I wanted to note something that would be helpful for team collab and source control - if that becomes more important to the C3 community.

Oh, I see. That makes more sense now.

I completely forgot there was any kind of UID conflict detection in C3. It doesn't seem like a good feature, because you can refer to UIDs in events, and so switching the UID can break the project. I checked our code logs and it looks like it exists solely for compatibility with C2 projects, probably because there was a bug in C2 that assigned duplicate UIDs or something. It's not there for the benefit of source control... but I guess it's one of these old backwards-compatibility hacks that people end up depending on anyway...

Similarly if Construct reassigns in-use image sprite IDs, you'll get jumbled animations using frames from the wrong objects, which doesn't seem great. I think a better approach is to use random number assignment, which Construct already does with SIDs for various purposes. I can't remember any reason why image sprite IDs need to be sequential or reasonably low numbers, but to be honest this is all super complicated code written years ago, so I'm not absolutely sure. Anyway I made a change for the next release to use random number assignment for image sprite IDs, so we'll see how that plays out. I don't think it's worth changing anything for UIDs since it's convenient for users to have low numbers if they're being manually entered.

Thanks! Very helpful, much appreciated. We will also help test after the changes.

Also, so you know, my quote about the UID conflict resolution in C2 was from the C2 SVN tutorial that you yourself wrote. (Seven years ago! So, I'm not surprised at all it may not have rung a bell):

From: construct.net/en/tutorials/collaborate-projects-svn-321

Oh gee, wow, that's some Construct archaeology right there 😆 I guess we had the same problem and solved it through reassignment back then, and that got carried over to C3. In general I think random IDs are the best way to solve this though.