Hi, Thanks for a great tool! It's strange that yoyo games hasn't fixed this issue already. I can't get it to work with inherited rooms though. All child rooms are lost from the yaml-file. Am I doing something wrong? Thanks!!
A downloadable tool for Windows
YY-YAML (pronounced "why, why - YAML") is an application that lets you convert between Game Maker Studio 2's project format (YYP +
views directory) and single-file nested YAML. In a sense, it is a successor to my older gmxorg tool.
This is primary intended for resolving merge conflicts when using version control software, which is generally considered to be one of the program's weakest points by professional users.
Source code is on GitHub.
How does this work
As you might be vaguely aware, GameMaker Studio 2 stores your project structure in a YYP file (which contains resource paths and resource IDs) and series of "view" files (which correspond each each "folder" that you can see in the resource tree).
Both of these are in JSON format, which is good for serialization purposes, but much less so for merging changes in version control - even adding a file to the end of the same resource tree folder on both branches is automatically a merge conflict due to lack of trailing comma as per JSON specification. Additionally, resolving merges is a mess because you cannot quickly look up which resources are used based on ID.
On other hand, this tool produces YAML files that are structured exactly like resource tree - so, if you had a folder called "helpers" with scripts "trace" and "cycle", it might look like:
- "helpers | GMScript | ... | ...": - "?trace | GMScript | ... | ..." - "?cycle | GMScript | ... | ..."
So each thing has its name/path, type, and both IDs all in the same line of YAML, which means that adding/removing resources/folders is a matter of changing a single line of code, and merge conflicts are less likely to occur to begin with.
Combine this with "interactive" merge modes in git clients like Sublime Merge, and working with version control is suddenly a breeze.
- Drag a YYP file onto the program's executable to generate a YAML version of it in the same directory.
- Drag such a YAML file onto the program's executable to update the YYP and view files to match its contents.
Obviously you can also use the two via command-line.
First, you want to make sure that your YAML is always updated together with YYP.
While you could just drag the YYP onto the executable manually, a nicer way of doing so is to instruct git to do so automatically.
For this you want to extract the
pre-commit file and place it in your
.git/hooks directory. Then place
YYYAML.exe in the project directory.
Then, when you have a merge conflict, you can resolve the merge conflict (if any) in the YAML file, and run the tool to update your YYP+views to match. Since YY-YAML's format has each resource/directory only take a single line, it makes it far easier to figure out changes, and many things will not result in a merge conflict at all (because YAML doesn't use delimiters like JSON does).
For applying to a merge conflict that you already have:
- Checkout a commit at the last merge point.
- Generate a YAML file of the project.
- Copy the file somewhere.
- Checkout the current commit at the source branch, do the same.
- Checkout the current commit at the destination branch, do the same.
- Commit the file from step 3 into the source branch and pull that single commit into the destination branch.
- Commit the file from step 4 into the source branch, but don't pull that yet.
- Commit the file from step 5 into the destination branch.
- Pull YAML changes from source branch into the destination branch, resolve merge conflicts, use the tool to generate a new YYP.
Reportedly, some project format changes are scheduled for GMS2.3, which should be out in late 2019. The exact nature of changes is not known at this time.
Click download now to get access to the following files:
Log in with itch.io to leave a comment.
Hi there, when I try to get this working, I get the following error:
"Couldn't find your YYP!" and the commit always fails.
You can see the file structure in the GIF below...
Super excited to get this working since I just spent about 6.5 hours doing one merge, so anything that can make this easier on me would be incredibly welcome.
If anyone can help me figure this one out please let me know!
As mentioned in the other comment, you will need to tweak the file to have the path to your project directory if it's not in the repository root directory.
Hello, sorry for my ignorance,nbut where do I put that...?
Does that go here?
for file in *.yyp; do
yyp_path = "drive/folder/folder"
This has been the biggest complaint with working with multiple people. Thanks so much for this.
If this is what I think this is, this could change everything for my team!
Will report back here after looking into it more.
Awesome. I'm looking forward to having this in my back pocket for the next #gittogether where it's nothing but conflicts and when we have conflicts at our studio, which is almost every week I feel. Thank you!
I'm not sure if this will get in the way of development on my mac, or if it will run without issue... I'll have to find out next time I'm on my mac.
We use a monolithic repo, so I'll have to rewrite the pre-commit to get it working in our main workflow, but this is great.
You'll want to either run it through Wine on Mac, or to compile from source code.
Should still work with a monolithic repo, as it would aid situations where two people work on adjacent items at once.
I'll let you know what happens when I try to get it working on the mac :)
I bet Wine will be fine. 🍷
Our monolithic repo is made of all our gms2 projects, server code and more.
So it doesn't find the .yy files. When it does it just finds the first one it looks like.
Haven't had a moment to really dig into it yet.
I'll have to refresh my bash skills to loop through all the subdirs and make it do it to all of them soon enough. 👏