Question - IDE Resource file is malformed (duplicate key), no way to get rid of this?

[DanjelRicci]

"Resource is malformed '(file path)' An item with the same key has already been added. Key: (key)"
Every now and then, one or more of these errors appear when I open my project. I constantly fix these by going into the project file and deleting the extra resources with the specified keys, making sure there's still the original resource there. It always works, all fine.

Problem is, when I commit the project via Git, the other computer pulls the project and the error appears again, even if using the new fixed project file. I also tried to fix the error on both computers simultaneously, but no matter what, the computer pulling the project will always get the error.
The only times I was able to "fix" this was because we just deleted the culprit files from the project, since they were no longer needed.

How do I definitely get rid of these errors when they appear?

 

[Jack S]

You are going to need notepad++ and some patience.

*MAKE A BACKUP OF YOUR PROJECT FILE - YOU ARE ABOUT TO DO SOMETHING BAD.

1. All the files it complains about in the popup - write them down. YoYo hates us and we can't copy paste the list.. x_x
2. Delete the references in your project (back the files up in a scratch folder on your computer so you can restore them later.)
3. Save and close project. - Make a second backup of your project as a restore point mid work. KEEP THE ORIGINAL BACKUP.
4. Open the project file in notepad++
5. Use Find (Ctrl+F) to search for the orphaned ghost entries.
6. Delete the entries 1 by 1. (This is why you removed the good ones from the project file - the ones left are the ghosts)
7. BE VERY CAREFUL TO NOT SCREW UP THE FORMATTING / STRUCTURE (while doing #6)
8. Save the fixed project file.
9. Open in GMS
10. Re-Add the files / resources from step 2. (you need the new .yy files, once those are in place you can actually use git to revert the file delete on the file itself *does not work on sprites due to file renames)
11. Save and CLOSE.
12. Open Project again to test.
13. Don't worry be happy - you just hacked your project file - commit to GIT. (Or restore backup and try again).

As for theory as to what happened - (from my teams experience)

User A: Deletes references in the project file (removes resource(s)) on Branch A.
User B: Makes any changes to the project file (add or removes resources(s)) on Branch A.
User A or B pushes to remote. (Whichever User deleted files - A or B if Delete)
Other User pulls from remote - Git while merging for some reason decides to only keep the additions to the file, not deleted blocks.
Project file gets saved and reloads - GMS doesn't care on a running reload - no User knows the project file has been corrupted.
Project file gets pushed into remote and other users get the project file cancer.

So I don't have to fix the project file often we have best practices in our team to keep this from happening.

1. We use master for production / hotfixes to production.
2. We use a version branch for project file changes to the next version. The is the root of changes to that version.
3. Bugs / Features are done in sub branches of that version branch. Any feature branch that makes a project file change MUST be pulled into the version branch right away. (We like to plan and placeholder as much as possible to avoid multiple project file updates from a feature branch)
4. Restructure / Cleanup / Big imports of content - always happens on the version branch.
5. When a feature / bug is done it's branch is pulled into the version branch.
6. Daily (or as needed) feature branches in progress pull from the version branch to get any updates / features of the version / project file updates / etc.
7. When it's time to deploy production we just pull the version branch down to master, set a tag for the version and make a new version branch

This makes it very easy to keep the project file from getting skraged and allows good source control practices and code reviews before merges/etc - and also is mostly compatible with pull request development pattern styles. (With exceptions to having to keep project file changes in sync or to specific branches.)