• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Question - IDE Issues when using Git or SVN with GMS2

J

jamiewhitephd

Guest
Hi there,

I recently upgraded my license to GMS2 so I may work on a project with some friends. For most projects (Unity/Unreal) we have used Tortoise SVN with Dropbox to commit work to each other and was hoping to do the same for this. This is really hard to explain in text form so bear with... When we attempted to commit work to each other we have found that everyone else's progress has been wiped and/or replaced with someone else's work upon updating.

Scenario example; I write some code that generates a level using a 2D array. At the same time, the artist is creating tiles using GMS2 for my code. I don't have these completed tiles yet, so I commit all of my changes and the Dropbox repo folder is updated. Artist saves work and closes GMS2. Artist then updates project folder using (Tortoise) SVN Update. Artist then re-opens the project and finds all work previously completed has vanished. The artist now, technically, has "my" version of the project, and can see the code I created but none of his work is in the resources tab. After opening the project in Windows Explorer, the artist can see all of the folders containing his created sprites, layers and so on, but GMS2 is unable to detect that they are there and has, essentially, lost all of that work.

I hope this makes sense... We have also tried using the Git plugin (Bitbucket), but every time we attempt to pull changes, GMS2 either crashes, or we do not get all of the updated files (as with above example).

Does anyone else have these issues? How do you normally collaborate with others using GMS2?
 
A

Albert Oldfield

Guest
I have also been experiencing issues with source control (Git) and GMS2. I'm working on a project with one other person, and it seems like every other Push/Pull that we do corrupts the project. Either some view file is missing, or a Guid in the yyp project file is mismatched. It's getting frustrating to say the least. We're both new to GMS2, and would also appreciate some guidance here. Any best practices, or recommendations when using GMS2 and Git (we're using Github, but it shouldn't matter) would be helpful (i.e. any files that should not be under source control in the .gitignore). We're not using the Git plugin inside GMS2 - since it doesn't feel all the way baked. Instead, we've been using GitKraken.
 

gnysek

Member
I reported it at beta stage, but they say it's not gonna be changed. But those random GUIDs+JSON are pain for merging projects when two developers are working. XML was better, mainly because every entry got it's own line, while in JSON adding something also changes a line before (because there's no comma after last entry). Also lot of data comes into several files (at least 4: project, views, resource info, resource), while in GMS1 it there was only item name under proper resource type node, and the rest was kept inside resource.

Creating one object by each person in resource tree makes project always corrupted.

Also after every save/change it scans whole repository, so when you quickly rename two resources in a bigger projects, there are error messages that there's lock on repository, and also it's generally super-slow because all rename/move/save actions are lagging because of "git status" on whole repository on each file.
 
J

jamiewhitephd

Guest
I reported it at beta stage, but they say it's not gonna be changed. But those random GUIDs+JSON are pain for merging projects when two developers are working. XML was better, mainly because every entry got it's own line, while in JSON adding something also changes a line before (because there's no comma after last entry). Also lot of data comes into several files (at least 4: project, views, resource info, resource), while in GMS1 it there was only item name under proper resource type node, and the rest was kept inside resource.

Creating one object by each person in resource tree makes project always corrupted.

Also after every save/change it scans whole repository, so when you quickly rename two resources in a bigger projects, there are error messages that there's lock on repository, and also it's generally super-slow because all rename/move/save actions are lagging because of "git status" on whole repository on each file.
Have you managed to work around it? Do you know why YoYo won't change/fix this? At the moment we are unable to continue working on the project in GMS2 which is very frustrating, especially so after paying for the update.
 
A

Albert Oldfield

Guest
We suspect that the main issue is with the yyp file, and two/more people editing the project structure (i.e. creating groups) at the same time. We're going to try to flesh out the groups in our project all at once to see how far that gets us. I'll post back here as to how successful that was. It's unfortunate that this is a problem, and I'm concerned that it will deter teams from creating with GMS2 in the future. I've been developing professionally for 15 years and have had experience with various IDE/Languages/Source Control and know how critical it is for a team to be able to collaborate effectively. Again, any guidance/suggestions/workarounds would be appreciated.
 

gnysek

Member
Have you managed to work around it? Do you know why YoYo won't change/fix this? At the moment we are unable to continue working on the project in GMS2 which is very frustrating, especially so after paying for the update.
They won't fix, as it's too late to change structure. They would need to rewrite whole IDE/compiler, which could take 3-4 months. It's only interesting how they didn't came to same issues when testing internally. Like there was no two developers on one project...
 
C

Curial Lloses

Guest
Good bless I've found this topic :_)

We have the same issues too and wondering if it is a bad idea using source control with GMS2 since we have reverted to clean commits several times from now and it is a huge time wasted.

As I've seen, IDE crashes if don't have related view files to any resource we create (sprite, object, sound or whatever) so if one of us changes anything in the resources tree and we have to merge a view file, we are doomed.

It is bad to read that seems it won't be fix for this... Is it not possible to make resources independent to views, projects and other tree files so we can just git.ignore them?
 

gnysek

Member
This could be partially possible if:
- resources are kept in real folders if they are in group in resource tree - this was partially implemented in GMS 1.4 at some point (directories were create, but files not yet moved inside)
- we drop file order in resource tree (they will be always sorted by name alphabetically), which is unaceptable, because resources ID are now based on their position on resource tree, so we would be forced to have different order

but, replacing GUID into resource names in YYG would make things easier, also, putting "null" as last value in jsons so it will be easier to merge as no comma is added to views at all:
Code:
"script_order": [
"65d2b823-851b-48a7-8043-d13309f75b36",
        "88a2f5e0-b480-45af-a3dc-55f217e9586b",
        "cdc94941-d150-43de-98dc-63803766cc0d",
        "0c8f31ad-e481-4737-9691-193905baa6e1",
        "61508ff3-0a92-41eb-baa3-189bab2d3a7b",
        null
    ],
    "tutorial": ""
}
so in above example, when new script is added, line "61508ff3-0a92-41eb-baa3-189bab2d3a7b" wouldn't be modified, when new resource added (while now it is).

Edit: I will try to make depth compare example between GMS1, GMS2 and some other language when have free time, to point out what's wrong. Maybe that will help them to see issues.
 
C

Curial Lloses

Guest
This could be partially possible if:
- resources are kept in real folders if they are in group in resource tree - this was partially implemented in GMS 1.4 at some point (directories were create, but files not yet moved inside)
- we drop file order in resource tree (they will be always sorted by name alphabetically), which is unaceptable, because resources ID are now based on their position on resource tree, so we would be forced to have different order

but, replacing GUID into resource names in YYG would make things easier, also, putting "null" as last value in jsons so it will be easier to merge as no comma is added to views at all:
Code:
"script_order": [
"65d2b823-851b-48a7-8043-d13309f75b36",
        "88a2f5e0-b480-45af-a3dc-55f217e9586b",
        "cdc94941-d150-43de-98dc-63803766cc0d",
        "0c8f31ad-e481-4737-9691-193905baa6e1",
        "61508ff3-0a92-41eb-baa3-189bab2d3a7b",
        null
    ],
    "tutorial": ""
}
so in above example, when new script is added, line "61508ff3-0a92-41eb-baa3-189bab2d3a7b" wouldn't be modified, when new resource added (while now it is).

Edit: I will try to make depth compare example between GMS1, GMS2 and some other language when have free time, to point out what's wrong. Maybe that will help them to see issues.
I would go further, replacing GUID into resources names could make easier for us to know wich lines to merge and at least -if not optimal- work safely.

Maybe is something able to do!
 

gnysek

Member
In case two users create object in empty project, and place them in room:

ON GMS1 - using merge tool, you just can use "mine first, theirs next" for both project/room files and conflict is solved (those are two XML lines in both cases).
Using GMS2 - yeah...:
gms2-git-merge.png
 
C

Crowstrum

Guest
So last night I ran into a similar problem. I added a few objects, while another dev had completely changed the file system (creating new groups, moving files, etc). So naturally I had merge conflicts when trying to push my changes into origin, that contained all the directory changes.

**I am not using Game Maker's built in git tools, that is a whole other issue that needs to be dealt with. So all of my version control is external to Game Maker.**

Unfortunately GUIDs are not very helpful for dealing with merge conflicts, so my first reaction to the merge conflict was to take both my branch changes and the changes in master and merge them together. This of course caused game maker to crash, and not load the project correctly. So I reverted my branch, and again pushed to master, but this time I kept only the changes on master, and none from my branch. Game Maker prompted me to reload the solution because there were changes made outside of the program (duh). Upon reloading I expected to have lost my objects and all of my branch's changes, but to my surprised everything merged correctly and nothing was missing. As a side note of the first merge conflict resolution, Game Maker did not ask to reload the project files, so maybe there is something going on there?

I'm just going to chalk this up to me getting lucky, and not that I found an actual solution to this problem. But seriously how do you allow an architecture decision to pass through to production, when it literally causes teams to fear every push and pull of their repository, and overall just wastes time.
 

Mike

nobody important
GMC Elder
We're changing the output so it's more like GMS1. it's still using GUIDS (as that's how it works), but each instance in a room will be on a single line which should make merging much easier. The "name" of the instance will be first followed by the GUID.

example.....
Code:
"instances": [
                    {"name": "inst_156264FF","id": "347732b1-8507-44ce-af8b-6b05dc3c3196","colour": { "Value": 4294967295 },"creationCodeFile": "","creationCodeType": "","ignore": false,"inheritCode": false,"inheritItemSettings": false,"IsDnD": false,"modelName": "GMRInstance","name_with_no_file_rename": "inst_156264FF","objId": "0ab50338-22ae-4124-9bfb-e30bfe8aea89","rotation": 0,"scaleX": 1,"scaleY": 1,"mvc": "1.0","x": 64,"y": 192},
                    {"name": "inst_5C5A21B3","id": "a823cb0a-9f6f-416a-9127-f14037a24013","colour": { "Value": 4294967295 },"creationCodeFile": "","creationCodeType": "","ignore": false,"inheritCode": false,"inheritItemSettings": false,"IsDnD": false,"modelName": "GMRInstance","name_with_no_file_rename": "inst_5C5A21B3","objId": "0ab50338-22ae-4124-9bfb-e30bfe8aea89","rotation": 0,"scaleX": 1,"scaleY": 1,"mvc": "1.0","x": 96,"y": 192}
]

Now... Most users don't name the instance much anyway so neither the name (nor guid) will help much. but, having it on line line should mean it will match and merge much better we think.

Same with assets.
 

gnysek

Member
I'm really happy to hear those changes are coming, cause one-lines would really help in this case :)

The only issue @Mike is still last entry and comma - if two users at same time would add resource at end of resource tree, or instance as last on list in room, on merge we would lose comma in JSON and break project, so I'm proposing this style of nodes:

Code:
"instances": [
                   {"name": "inst_156264FF","id": "347732b1-8507-44ce-af8b-6b05dc3c3196","colour": { "Value": 4294967295 },"creationCodeFile": "","creationCodeType": "","ignore": false,"inheritCode": false,"inheritItemSettings": false,"IsDnD": false,"modelName": "GMRInstance","name_with_no_file_rename": "inst_156264FF","objId": "0ab50338-22ae-4124-9bfb-e30bfe8aea89","rotation": 0,"scaleX": 1,"scaleY": 1,"mvc": "1.0","x": 64,"y": 192},
                   {"name": "inst_5C5A21B3","id": "a823cb0a-9f6f-416a-9127-f14037a24013","colour": { "Value": 4294967295 },"creationCodeFile": "","creationCodeType": "","ignore": false,"inheritCode": false,"inheritItemSettings": false,"IsDnD": false,"modelName": "GMRInstance","name_with_no_file_rename": "inst_5C5A21B3","objId": "0ab50338-22ae-4124-9bfb-e30bfe8aea89","rotation": 0,"scaleX": 1,"scaleY": 1,"mvc": "1.0","x": 96,"y": 192},
                   {}
]
An empty value/object at end of "instances" array :) This should solve lot of problems on merge.
 

Mike

nobody important
GMC Elder
If 2 folk add something at the same time, you would now simply do merge "both". Since the GUIDs will be different each line will differ, and you can simply select both items.
If someone removes one thing and adds another, then again due to the GUID and everything on one line, this should again work properly.

Source control works on "lines" not characters, so it will change/replace the while line.
 

GMWolf

aka fel666
If 2 folk add something at the same time, you would now simply do merge "both". Since the GUIDs will be different each line will differ, and you can simply select both items.
If someone removes one thing and adds another, then again due to the GUID and everything on one line, this should again work properly.

Source control works on "lines" not characters, so it will change/replace the while line.
Yes but the problem remains:
If two commits add entries at the end of the list, after merging, the last two lines will be missing the trailing comma. (OK for the last entry, but wrong for the second to last one).

This is a problem with the json format.
An easy fix would be to have a dummy entry at the end of the list, such that you always have a comma after an entry. That should stop json from breaking.
 

gnysek

Member
If 2 folk add something at the same time, you would now simply do merge "both". Since the GUIDs will be different each line will differ, and you can simply select both items.
If someone removes one thing and adds another, then again due to the GUID and everything on one line, this should again work properly.

Source control works on "lines" not characters, so it will change/replace the while line.
Yeah, but JSON omit comma at last element. Repository before any changes:
Code:
"instances": []
User 1, named Tom, adds his instance to room_0 (I will use shortened code so it's more readable):
Code:
"instances": [
    {"name": "inst_156264FF","id": "347732b1-8507-44ce-af8b-6b05dc3c3196"}
]
User 2, named Jim, adds his instances (not yet puled Tom changes):
Code:
"instances": [
   {"name": "inst_253C264FF","id": "12732b1-8507-44ce-af8b-6b05dc3c3196"},
   {"name":"inst_5C5A21B3","id": "a823cb0a-9f6f-416a-9127-f14037a24013"}
]
So, after Jim want to push, he need to first merge Tom' changes, with "their before mine" solution, we have:
Code:
"instances": [
   {"name": "inst_156264FF","id": "347732b1-8507-44ce-af8b-6b05dc3c3196"}
   {"name": "inst_253C264FF","id": "12732b1-8507-44ce-af8b-6b05dc3c3196"},
   {"name": "inst_5C5A21B3","id": "a823cb0a-9f6f-416a-9127-f14037a24013"}
]
As you see, there's missing comma in first line. If there was an empty entry {} at end of list, line added by Tom would have comma at and, and automatic merging would make valid project. This way - it will be broken, and most of GMS users wouldn't be able to find it out.



Same, with empty {} at end:

Commit 1:
Code:
"instances": [
    {"name": "inst_156264FF","id": "347732b1-8507-44ce-af8b-6b05dc3c3196"},
    {}
]
Commit 2:
Code:
"instances": [
   {"name": "inst_253C264FF","id": "12732b1-8507-44ce-af8b-6b05dc3c3196"},
   {"name": "inst_5C5A21B3","id": "a823cb0a-9f6f-416a-9127-f14037a24013"},
   {}
]
Merged:
"instances": [
{"name": "inst_156264FF","id": "347732b1-8507-44ce-af8b-6b05dc3c3196"},
{"name": "inst_253C264FF","id": "12732b1-8507-44ce-af8b-6b05dc3c3196"},
{"name": "inst_5C5A21B3","id": "a823cb0a-9f6f-416a-9127-f14037a24013"},

{}
]
 
Last edited:
J

jamiewhitephd

Guest
Thanks everyone for your input. So to clarify, there is no easy fix for this issue? The only way is to merge everything manually?
 

gnysek

Member
For now there's no better way, and there's no fix for it yet in next release (I'm 90% sure, but they may surprise us).
 
M

MJamesShort

Guest
Checking in to see if this has been resolved yet. Massive problems for people working as teams and having to do manual merges is just a pain.
 

Yal

šŸ§ *penguin noises*
GMC Elder
Stumbled over this topic, gonna follow it to see what happens. Source control is pretty important in production environments and having major integration issues with the most common tools doesn't really fit GM's new professional image.
 

GMWolf

aka fel666
Stumbled over this topic, gonna follow it to see what happens. Source control is pretty important in production environments and having major integration issues with the most common tools doesn't really fit GM's new professional image.
The key term here is 'image'.
YYG want to make their tool look more professional (new chain workflow, better room editor), but the fundamental flaws GM has always had haven't really been addressed (poor language, poor 3rd party support, poor extensibility, poor team workflow...).

I mean seriously, picture a team project with three team members.
One of the team members works on addi ng monsters into the game, the other works on the shadows and line of sight.
A third works on the sprites and graphics of enemies.

The first team member decides to add a new monster. It is a sort of shadow mo nster so he neame a new object "oShadow" and references it in a bujnch of the code to handle it's collision, etc.
The second team member adds an object to handle the shadows and so also creates an object names "oShadow" and references it throughout the line of sight and shadowing code.
The third team member decides to add a drop shadow to all monsters and adds an object names "oshadow" as well.

Once they are all done with their work, thet test it and then commit it to the remote repository.
But horrors! Now the team has a horrendous refactoring mess to take care of!
Assuming the commit order was member 1, 2 and 3; the second team member may choose to rename the shadow monster object to "oShadowMonster", but what if he missed a bit of code to refactor? now the code may be referencing the wrong object!
And what of the third team member! the problems keep compounding!

Now, the team members may decide all monsters start with a monster prefix, etc. But what about importing assets! What if they have a resource or variable you are already / will use?
Worse, what if two assets are using the same resource name, variables, etc. Now its impossible to do anything!!!


Verdict:

GMS2 was the chance for YYG to move away from these problems by introducing new language constructs, and moving away from difficult file formats.

But not only did they not add any new lanuage features to remedy such problems, they didn't even do their research and made the problem worse by using json as file format for everything!
Don't get me wrong, i love json, but its just not the right tool for the job in this case (its a rare case where XML makes a lot more sense...)

I have to say im a little disappointed in YYG. they have a great team, with a lot of talent, Yet the progress on GM is slower than ever, and they seem to be progressing backwards, prioritising outwards appearances over functionality.

Also whats up with UUIDs? Are they really nessarry? Shouldn't a file structure be enough? Or if you really like a central project file, the fact that they are separate entries should do the trick...
 
Last edited:

gnysek

Member
Also whats up with UUIDs? Are they really nessarry? Shouldn't a file structure be enough? Or if you really like a central project file, the fact that they are separate entries should do the trick...
The problem is that now, about two years since they working on GMS2, it's too late to make so much breaking change. I also think that for most of resources, yyg config files aren't needed at all (this would remove "additional tree views" in resource tree, but it still could be possible in other ways), or with minimal config (like in GMS 1.x), however this was their decision and we cannot do anything with it now. I pointed it out in several places, and every time answer was "we won't change it, we like it, even if it's not ideal".
 

FrostyCat

Redemption Seeker
Also whats up with UUIDs? Are they really nessarry? Shouldn't a file structure be enough? Or if you really like a central project file, the fact that they are separate entries should do the trick...
More recent versions of GMS 2 save the .yy files using the original resource names. UUIDs are now only used for things that make no sense outside the current .yy file, for example instances in a room, and various scattered data in the views directory.
 

GMWolf

aka fel666
More recent versions of GMS 2 save the .yy files using the original resource names. UUIDs are now only used for things that make no sense outside the current .yy file, for example instances in a room, and various scattered data in the views directory.
Oh is that right? Cool! Viery useful to know.
 
Y

Yury

Guest
My experience with merging project (2 devs):

A lot of time wasted merging guids, figuring out its mine added, or other's deleted. Have to search what this guid means, this is nightmare. Unity devs laugh at me.
I consider GMS2 as solo-only tool for now.
 

gnysek

Member
I consider GMS2 as solo-only tool for now.
Or one developer adds new content (resources/code), one touches only room instances and can fix code but not change order/rename instances/resources. For 3 persons... no way.

But all having free way to make a game - there's no way.
 

Yal

šŸ§ *penguin noises*
GMC Elder
So is this crap fixed yet? <reads new posts> okay nope

My current workflow is like this:
  1. Make stuff in GMS1 (being aware of changes in GMS2)
  2. Convert to GMS2 project at the very end and make sure it compiles
  3. Throw away GMS2 project because I don't need it anymore
It's not really optimal, but it should be sufficient until GMS2 gets its **** together. You still get a free GMS1 license with every GMS2 license you buy right?
 

gnysek

Member
Sadly, XML used in GMS1 was better. Maybe it seems that XML takes more bytes than JSON because of opening and closing tags, but in fact YYG added so many other metadata to those files, that output is not only 50% - 200% bigger than in GMS2, but is not usable with GIT because of it's structure (one-per-line in XML was more safe, easy to manual edit in any text editor, and very easy when it come to merge, while JSON+GUIDS should burn same as Delphi IDE, mainly cause of randomness and comma at end issues).
 

Yal

šŸ§ *penguin noises*
GMC Elder
So if YYG are so big fans of stuff that's incompatible with source control, does that mean they're not actually using source control while developing GM...? Not sure if I like the sound of that.
 

FrostyCat

Redemption Seeker
So if YYG are so big fans of stuff that's incompatible with source control, does that mean they're not actually using source control while developing GM...? Not sure if I like the sound of that.
YoYo most certainly does use source control. It's common for tickets on Mantis to be closed with a post mentioning the commit instead of a concrete version number. Here is an example with several commits in series.

The big problem with source control on both versions of GMS is that it has mostly been tested with trivial linear flows only early on. That isn't surprising since much of the beta-testing population were amateur soloists, and source control friendliness wasn't part of day one's game plan (in fact it had been non-existent or non-functional for most of the closed beta period). Add branching or collaboration of any sort and that's untested territory, at least until the public release. Anyone who understands release cycle theory would know that GMS 2 is now at a stage where addressing this problem is an albatross.

It's easy to see why YoYo would get the false impression that everything is fine for so long. And it's also easy to see why this might persist as a GMS 3 issue and beyond.
 

GMWolf

aka fel666
But am I right in thinking adding a guard resource at the end of lists would fix that problem?
And if so, why is it not implemented yet?
 

JAG

Member
just included a second dev on my project, it has not gone well with Git so far. How are people working around this? I know eg Nidhogg 2 was made with GM and their teams was at least 4-5 people; are they maybe still using GMS1?

We manually merged the yyp file, line by line, after getting a bunch of merge conflicts. After fixing all the conflicts the project will not boot, and its not clear why. How can we continue working together without source control??
 

GMWolf

aka fel666
just included a second dev on my project, it has not gone well with Git so far. How are people working around this? I know eg Nidhogg 2 was made with GM and their teams was at least 4-5 people; are they maybe still using GMS1?

We manually merged the yyp file, line by line, after getting a bunch of merge conflicts. After fixing all the conflicts the project will not boot, and its not clear why. How can we continue working together without source control??
I guess the community could build a converter o convert from .yy to a git friendly format.
But the amount of converting between formats would make this quite unappealing.

I dont think there is a real workaround, YYG just have to face the facts and fix it.
I would say having a system based around the file system rather than centralized files would fix many issues, But YYG dont seem to be of that opinion.
That is, have a central file that represents the project, but doesn't store references to resources. Instead those would be scanned for in the file system.
It would make managing projects far easier.
 

JAG

Member
I do think the "proper fix" conversation is a good one to have, but right now Im mostly concerned with the fact that my friend created a new feature and made some small project structure changes and literally cannot get his stuff into the game after hours of trying.

I would either like to know if there's a process (even a painstaking unreasonable one) to fix this immediate problem (a json-valid merged .yyp that is somehow corrupt), or if not, how are other people even working on a game together?
 

JAG

Member
merge, then fix by hand....
hm yeah that's what we did, and the yyp looks fine (in terms of json syntax) but GM will not boot the game, it just crashes. There must be some .yyp processing rules that we're violating? Do resource blobs need to be ordered in a particular way or something?
 

GMWolf

aka fel666
hm yeah that's what we did, and the yyp looks fine (in terms of json syntax) but GM will not boot the game, it just crashes. There must be some .yyp processing rules that we're violating? Do resource blobs need to be ordered in a particular way or something?
not sure, make sure non of the resources have the same ID
 
  • Like
Reactions: JAG
B

BlueLemming

Guest
This thread is quite concerning. So what's the general consensus on this? Stick to GMS:1 if collaborating? I've been starting up a project in GMS:2 and would like to add someone to the project soon, but if it's at the risk of blowing up my project on each merge... then I'd rather just migrate it to GMS:1 if that's more reliable.
 

Mick

Member
This is a big problem indeed. We have been using git with gms1.4 (three man team), and it has mostly worked without problems. A few conflicts here and there but those have been due to overlapping code changes.

As it is now with the source control issues in gms2, I can't migrate even if I have the license and would like to. There's no way I would go back to not using source control.

I know that some issues have been fixed, what is usually breaking merging at the moment? Could a more simple "conversion" script help, like adding a comma after the last resource in a group etc.?
 

gnysek

Member
Yeah, conflicts in 1.4 are solvable, because XML is easy to read.

But if you have something like this:
upload_2017-11-6_16-19-40.png
it's hard to merge if somebody made another commit, as those GUIDs tells you nothing. GMS 1.4 was billion times easier to read in case of merge.

Also as you notice, in fact only one line should be modified in this case. But since JSON syntax doesn't allow comma on last line, adding something to game will always modify two lines. If two developers added new object to game, you will have a problem with lost commas when merging ("using their before mine" and similar solutions), as JSON won't be valid and project won't open, or some resources will vanish.
 

Yal

šŸ§ *penguin noises*
GMC Elder
How about a compromise solution? Have a "use JSON for internal resource management" option somewhere in the options menu, add an alternate XML format, have it clearly stated to be experimental for a bit, but keep that oh-so-cool JSON thing if people really want it (and have it on by default so people won't risk have their stuff broken unless they want to). JSONers and XMLers both get what they want, everyone's happy.
 

Mick

Member
How about a compromise solution? Have a "use JSON for internal resource management" option somewhere in the options menu, add an alternate XML format, have it clearly stated to be experimental for a bit, but keep that oh-so-cool JSON thing if people really want it (and have it on by default so people won't risk have their stuff broken unless they want to). JSONers and XMLers both get what they want, everyone's happy.
Sounds good! :) It shouldn't be too big an issue to add an alternative xml format using (de)serialization. I hope this issue gets fixed one way or another, it's a quite serious problem in my opinion.
 
  • Like
Reactions: JAG

GMWolf

aka fel666
That would only help if we're using Git using the command line or an external GUI tool. The Git integration in GMS 2 is hard-wired as a library.

Still, a promising find. I'll experiment with several conflict scenarios and see how well it handles.
Yeah, but assuming it works, it would help YYG right?
 

FrostyCat

Redemption Seeker
OK, I think I've got it. Here's how to get git-json-merge working with GMS 2:
  • Install NPM and Node.js.
  • Run npm install -g git-json-merge. If you're on Mac, you may need to prepend sudo.
  • Add this to .gitattributes in the working copy's root directory:
Code:
*.json merge=json
*.yyp merge=json
*.yy merge=json
  • Add this to .gitconfig in the working copy's root directory:
Code:
[merge "json"]
    name = custom merge driver for json files
    driver = git-json-merge %A %O %B
  • Commit and push if necessary. If working with a collaborator, make sure they all pull and install the merge tool.

Now you can locally try a quick conflict scenario:
  • Create a blank project and check it into master.
  • Fork out two branches dev-a and dev-b from master, and add a different object in each and commit.
  • Fork a branch exp-merge from dev-a, then merge dev-b.
You will see that the main .yyp file auto-merges correctly. The remaining conflict is in views for the objects folder group, which would have required manual resolution anyways because this is an AB vs. AC situation.
 
Last edited:
Top