• 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

gnysek

Member
The solution for JSON is easy in fact, but adds a lot of unused data:

Code:
"node-name": value,
"node-name": value,
"node-name": value,
"node-name": value,
"-": null
}
so the last line will never change.
 
D

Daren Barnett

Guest
Use the github desktop and have the devs each create a branch. If you have failed merges you still have the branches to manually fix the problem
 

Mick

Member
Has anybody managed to get (external) source control working properly yet?

I have been experimenting a little with git-json-merge and without. Before I installed git-json-merge there was a lot of conflicts that I needed to take care of manually, with git-json-merge I did the same experiment of adding an object in two different branches. They were merged automatically but the project was broken after that so I guess git-json-merge is not a solution.

This is a serious issue, does anybody have any workarounds?
 
Last edited:

Mick

Member
The next version will have the changes to room saving to help with this. We still need to look at trying to add the "empty" last entry at some point though.
The changes to the room.yy files (single line for each resource) was a good idea. Any chance of making the same change to the project.yyp file and adding the "empty" last entry?

Each resource could be on it's own single line. That would help a lot I think.

(The json below would be one single line)
Code:
{
    "Key": "2a81340c-ecc4-4b90-a99c-d4d0c00914d5",
    "Value": {
        "id": "3c9f3282-242b-47aa-baa7-0f5ec2034215",
        "resourcePath": "objects\\object1a\\object1a.yy",
        "resourceType": "GMObject"
    }
},
 

FrostyCat

Redemption Seeker
I've revisited this issue recently, and I strongly suggest the following changes to the GMS 2 file format:
  • Using actual directory structures to represent folder groups instead of emulating them with a bunch of files in the views directory
  • Allow the .yyp file and the views directory to be ignored or checked in blank, and automatically generate the resource tree structure on load/import.
The views directory and the .yyp file in the GMS 2 project format are the biggest barriers to GMS 2's source control friendliness, not the JSON terminating comma problem. In fact, the JSON terminating comma problem is directly and mostly caused by the format design in these two places.

With or without git-merge-json, every merge conflict I've tested happened either in views or the .yyp file. Everything in my views folder at this point are basically folder nodes that don't affect the compile-time semantics of the project, and in a merge situation, all they do is complicating the merge by fighting over what their children are. The .yyp file does the same crap, and the result is like trying to fix a bookshelf with the books still on it. Simply by not reinventing the wheel with directory structures, this whole class of conflicts could have been eliminated. And with plain resources already being saved by name, these two changes alone are enough to make source control viable again for GMS 2.

People who use source control don't leave unlinked files in their projects to serve as backups, they aren't fussy about exact file orderings, and they don't aggressively jiggle hierarchies or rename existing resources. So please stop bending over backwards to satisfy petty compulsions about neatness and order from people who don't know the anti-collaborative costs of these compulsions. You cannot invite serious professional use of GMS 2 if it does not work with source control, period --- that's more important than making sure A always appears before B on a folder tree.
 

GMWolf

aka fel666
A central file solution seems a little archaic. Yes VS still does it, but it's the most anoyanno thing ever.
Much better to go the folder structure route. Far easier to work with outside the IDE, and a much more robust solution.
 

Mick

Member
The views directory and the .yyp file in the GMS 2 project format are the biggest barriers to GMS 2's source control friendliness, not the JSON terminating comma problem. In fact, the JSON terminating comma problem is directly and mostly caused by the format design in these two places.
I have been experimenting today with the project files and git. I noticed that GMS2 will load the project files without problem even if there is a comma after the last item in a json array. Like you (FrostyCat) said, the commas are not the biggest issue, now it's probably the resources in the .yyp file taking multiple lines.

To test how things could be improved, I created a command line tool that compacts resources (.yyp) and object events (object.yy) to one line only. It also adds commas after the last item in some arrays in the .yyp file, the views .yy files and the object .yy files. I just run the tool to process the project files before doing a commit. It really helps source control a lot. This is just a hack but still promising.

This is how a project.yyp file will look after being processed:
Code:
{
    "id": "1945f26a-048a-43ee-9269-8426321032a9",
    "modelName": "GMProject",
    "mvc": "1.0",
    "IsDnDProject": false,
    "configs": [
       
    ],
    "option_ecma": false,
    "parentProject": {
        "id": "9bbdffa1-967e-410e-b72b-333166fe906c",
        "modelName": "GMProjectParent",
        "mvc": "1.0",
        "alteredResources": [
            {
                "Key": "ed6a955d-5826-4f98-a450-10b414266c27",
                "Value": {
                    "configDeltas": [
                        "inherited"
                    ],
                    "id": "acab9941-dbb9-413e-9909-78f812a7009e",
                    "resourcePath": "options\\main\\options_main.yy",
                    "resourceType": "GMMainOptions"
                }
            }
        ],
        "hiddenResources": [
           
        ],
        "projectPath": "${base_project}"
    },
    "resources": [
        {"Key": "10643e24-01ee-421b-9e88-8e72fe7cbe8e","Value": {"id": "bd86168d-460b-43dd-8c04-4b1e1a672622","resourcePath": "objects\\object1b\\object1b.yy","resourceType": "GMObject"}},
        {"Key": "1a1d1753-ca99-4e7b-b993-72f1c4e09f4f","Value": {"id": "4e64bf9f-937d-490e-b09e-e7d0c1d7e5c3","resourcePath": "timelines\\timeline0\\timeline0.yy","resourceType": "GMTimeline"}},
        {"Key": "279c9e6f-f38a-44b5-855a-c474ca47fc11","Value": {"id": "a1bee0ab-504f-460f-9549-5982eb27b3d4","resourcePath": "objects\\object3\\object3.yy","resourceType": "GMObject"}},
        {"Key": "28ceca09-9c4a-4aeb-bb4c-4045d54f5927","Value": {"id": "59d6ba3c-5586-439a-b0c4-a1ca8a4efb1a","resourcePath": "views\\28ceca09-9c4a-4aeb-bb4c-4045d54f5927.yy","resourceType": "GMFolder"}},
        {"Key": "29fe1e41-4e00-4096-803d-841b57e02d84","Value": {"id": "ef30b473-1764-4982-bfcb-d5633329d896","resourcePath": "scripts\\script0\\script0.yy","resourceType": "GMScript"}},
        {"Key": "2a81340c-ecc4-4b90-a99c-d4d0c00914d5","Value": {"id": "3c9f3282-242b-47aa-baa7-0f5ec2034215","resourcePath": "objects\\object1a\\object1a.yy","resourceType": "GMObject"}},
        {"Key": "2f4a92d1-87b6-4b72-8da4-35f8b5beb0fa","Value": {"id": "68450e51-3ccf-4983-a7ab-af833430751d","resourcePath": "views\\2f4a92d1-87b6-4b72-8da4-35f8b5beb0fa.yy","resourceType": "GMFolder"}},
        {"Key": "32fe58ee-5828-4ce9-80dc-e7fe6f9ec526","Value": {"id": "7527aa01-f7bd-4cab-8238-483fbdf45fbe","resourcePath": "tilesets\\tileset0\\tileset0.yy","resourceType": "GMTileSet"}},
        {"Key": "4911ad76-5ca0-4fae-ba08-c2803b9af4da","Value": {"id": "b21e3e9e-0f25-4d32-9584-b558ac56c139","resourcePath": "views\\4911ad76-5ca0-4fae-ba08-c2803b9af4da.yy","resourceType": "GMFolder"}},
        {"Key": "5295fc42-3342-40bd-9489-868c3cc05412","Value": {"id": "7225293c-1c85-46c7-bb3e-d3a91b09edea","resourcePath": "views\\5295fc42-3342-40bd-9489-868c3cc05412.yy","resourceType": "GMFolder"}},
        {"Key": "53e98933-e92d-48cf-a2b1-29468d01a87e","Value": {"id": "44e31e86-7bf0-4755-9be8-0ea391f40116","resourcePath": "views\\53e98933-e92d-48cf-a2b1-29468d01a87e.yy","resourceType": "GMFolder"}},
        {"Key": "57052ca8-d8ed-46d8-9652-98f98ffd49c6","Value": {"id": "c5ce9c4a-8ad9-4474-8159-6a07074dd9a0","resourcePath": "views\\57052ca8-d8ed-46d8-9652-98f98ffd49c6.yy","resourceType": "GMFolder"}},
        {"Key": "584337e9-4b8c-418b-94fa-7b2fadd507db","Value": {"id": "14af707d-e550-43ab-bfd1-279ab419882d","resourcePath": "fonts\\font0\\font0.yy","resourceType": "GMFont"}},
        {"Key": "5bb2cd95-ef76-498f-8627-b4024bd1c8c1","Value": {"id": "e6338fad-5735-4bc7-be47-07f358ea89d5","resourcePath": "paths\\path0\\path0.yy","resourceType": "GMPath"}},
        {"Key": "5e0d453b-6df2-48df-976f-d0b2fc778363","Value": {"id": "5f5ca9e6-a593-416e-94e3-63d7a84e3768","resourcePath": "views\\5e0d453b-6df2-48df-976f-d0b2fc778363.yy","resourceType": "GMFolder"}},
        {"Key": "6ab86d1f-fb2b-4263-a1c4-8447f6e07c0c","Value": {"id": "f9c941a7-8163-476b-b7fd-6c74a01c61ae","resourcePath": "views\\6ab86d1f-fb2b-4263-a1c4-8447f6e07c0c.yy","resourceType": "GMFolder"}},
        {"Key": "6d92a932-aebd-46c0-aa1b-137f8cc70f74","Value": {"id": "749e1a33-a85b-475e-a89f-1dd44cf18857","resourcePath": "rooms\\rm_room1\\rm_room1.yy","resourceType": "GMRoom"}},
        {"Key": "766aab0c-4f6b-4b49-9dfa-e62b1c641916","Value": {"id": "68abc835-f1be-4988-9940-cf98442c143b","resourcePath": "views\\766aab0c-4f6b-4b49-9dfa-e62b1c641916.yy","resourceType": "GMFolder"}},
        {"Key": "7e093a2a-e51c-4a1e-9a53-f9080d38730b","Value": {"id": "50bc08b2-f92b-43db-ad16-059b6e6ca091","resourcePath": "options\\windowsuap\\options_windowsuap.yy","resourceType": "GMWindowsUAPOptions"}},
        {"Key": "7fbd1320-9591-49bf-b426-3dc71969977d","Value": {"id": "52e6df83-d3fa-4008-b970-d1195f9ffa68","resourcePath": "views\\7fbd1320-9591-49bf-b426-3dc71969977d.yy","resourceType": "GMFolder"}},
        {"Key": "810bf281-a393-4464-931a-ad5fb73ec1b3","Value": {"id": "2b725558-31b5-4584-a8f2-49ceb63b0985","resourcePath": "sounds\\sound1\\sound1.yy","resourceType": "GMSound"}},
        {"Key": "8427047f-9ef8-4c77-89f3-9c20623d07b6","Value": {"id": "281570f3-8c9e-4a7f-af97-9412893f55bb","resourcePath": "options\\ios\\options_ios.yy","resourceType": "GMiOSOptions"}},
        {"Key": "88f8ebf1-325b-4e40-ae56-83bb7cbb5ff7","Value": {"id": "c1497b8e-83e2-4139-8464-711b6d97b69e","resourcePath": "views\\88f8ebf1-325b-4e40-ae56-83bb7cbb5ff7.yy","resourceType": "GMFolder"}},
        {"Key": "8babc2ea-bbb9-4a2e-9ac9-398f462f4e54","Value": {"id": "d25b37b3-84c9-4412-969d-723e94594a45","resourcePath": "views\\8babc2ea-bbb9-4a2e-9ac9-398f462f4e54.yy","resourceType": "GMFolder"}},
        {"Key": "947296f1-447a-4bf2-8218-5bc1aad89c2c","Value": {"id": "7ae1e0b2-8bc4-46c7-bdfb-18a3769fe285","resourcePath": "objects\\object6\\object6.yy","resourceType": "GMObject"}},
        {"Key": "a128950b-5063-4876-b4a6-b99dbd2ea6d1","Value": {"id": "48f2c1ae-b949-4524-8630-ce7c9479ad7d","resourcePath": "options\\amazonfire\\options_amazonfire.yy","resourceType": "GMAmazonFireOptions"}},
        {"Key": "a9188620-a624-4a5a-83ae-a1b53faf038b","Value": {"id": "7288f6a7-cb9d-431f-ba04-dfb6f4fe1fbd","resourcePath": "options\\linux\\options_linux.yy","resourceType": "GMLinuxOptions"}},
        {"Key": "aa81b047-386e-4fa6-a6bf-98cac000b3d6","Value": {"id": "3a37bb52-b879-4305-bfb5-4336c3214ae0","resourcePath": "scripts\\script3\\script3.yy","resourceType": "GMScript"}},
        {"Key": "abd147f8-0e79-49df-be09-89246d2394b8","Value": {"id": "4373bb12-c180-4961-b080-d2635ad5ebbe","resourcePath": "paths\\path1\\path1.yy","resourceType": "GMPath"}},
        {"Key": "b5209d12-364c-4efe-9695-6e6251799253","Value": {"id": "ecfd16e0-d1f6-4aa0-bfce-fe661f3bda3c","resourcePath": "objects\\object5\\object5.yy","resourceType": "GMObject"}},
        {"Key": "b906d7ce-288f-4ae7-a5b4-a0e33136ad9a","Value": {"id": "97caccc1-c250-401b-8ae0-fc5309429e7e","resourcePath": "scripts\\script1\\script1.yy","resourceType": "GMScript"}},
        {"Key": "c3a61052-a64e-4d7a-87a5-d0c85b56146c","Value": {"id": "08e847ba-0136-4a13-9e2a-87c015fd3459","resourcePath": "objects\\object2\\object2.yy","resourceType": "GMObject"}},
        {"Key": "cbdf4a2c-7629-4c23-a1ea-75422e2681a6","Value": {"id": "2edfc3b6-e443-442d-89bc-881ecf11b37a","resourcePath": "objects\\object4\\object4.yy","resourceType": "GMObject"}},
        {"Key": "cc98d028-7bdd-4680-85f3-c87a7baa481e","Value": {"id": "ca4ce011-26c8-468d-9096-af0b144c9310","resourcePath": "options\\windows\\options_windows.yy","resourceType": "GMWindowsOptions"}},
        {"Key": "cd911a5e-7c17-4c58-8cd7-0640f7c44292","Value": {"id": "46ad3b9e-ba40-4279-8328-05c2a670de29","resourcePath": "sounds\\sound0\\sound0.yy","resourceType": "GMSound"}},
        {"Key": "d177c87c-4aa0-4b4c-b25c-df2375d68278","Value": {"id": "81cc19db-ac04-4b3a-a084-c0c44e6a5ed2","resourcePath": "views\\d177c87c-4aa0-4b4c-b25c-df2375d68278.yy","resourceType": "GMFolder"}},
        {"Key": "d88562a4-829b-44e8-b79f-631ca6c89389","Value": {"id": "61b52af1-4c8f-4e26-81ca-7eacc8dbb4ac","resourcePath": "views\\d88562a4-829b-44e8-b79f-631ca6c89389.yy","resourceType": "GMFolder"}},
        {"Key": "e0eebd6a-c3ab-4559-ae74-5eecc7dc8bc7","Value": {"id": "df536780-f7d0-4cb1-982d-78b91759fea5","resourcePath": "rooms\\rm_mytest_room\\rm_mytest_room.yy","resourceType": "GMRoom"}},
        {"Key": "e42bf5cc-3f46-4d67-a6d0-a4885a11ac3f","Value": {"id": "74ace3f7-a830-4a7f-86ec-5522f8210bd2","resourcePath": "options\\android\\options_android.yy","resourceType": "GMAndroidOptions"}},
        {"Key": "e586b14f-040f-4d4d-8ef1-d2d9aa9af362","Value": {"id": "e01d0c7e-7a92-429e-8baf-66a9f7c1b811","resourcePath": "shaders\\shader0\\shader0.yy","resourceType": "GMShader"}},
        {"Key": "ea10a2d1-53e8-4a0f-88bd-01c3e2ef6f21","Value": {"id": "ad619105-32d9-4d1d-be13-c058cfd31136","resourcePath": "sprites\\sprite0\\sprite0.yy","resourceType": "GMSprite"}},
        {"Key": "f166493d-a992-43b0-8b5c-9e63de34e3fd","Value": {"id": "c72081a2-3d76-4f94-b7b6-99d22de89e2d","resourcePath": "views\\f166493d-a992-43b0-8b5c-9e63de34e3fd.yy","resourceType": "GMFolder"}},
        {"Key": "f418569b-3bdd-4706-a0e4-364317f54032","Value": {"id": "5c3f5a97-8307-4730-ac88-2094e135c7b5","resourcePath": "options\\mac\\options_mac.yy","resourceType": "GMMacOptions"}},
        {"Key": "faaf2949-a721-4b6d-8482-c5970a05818b","Value": {"id": "b1c69330-15b1-437d-962e-d09023fdec5a","resourcePath": "views\\faaf2949-a721-4b6d-8482-c5970a05818b.yy","resourceType": "GMFolder"}},
        {"Key": "fb18b414-6130-47a1-9589-648ec311418d","Value": {"id": "5939e628-513e-4b89-a3c8-24638faba8be","resourcePath": "scripts\\script2\\script2.yy","resourceType": "GMScript"}},
    ],
    "script_order": [
        "aa81b047-386e-4fa6-a6bf-98cac000b3d6",
        "fb18b414-6130-47a1-9589-648ec311418d",
        "b906d7ce-288f-4ae7-a5b4-a0e33136ad9a",
        "29fe1e41-4e00-4096-803d-841b57e02d84",
    ],
    "tutorial": ""
}

The tool creates backups of the files before they are processed (I added the .backup files to .gitignore). This is just an experiment but if somebody wants to try the tool on a test project or something then it can be found here: http://gamephase.net/files/GMS2GitProcess.zip

You run it with one parameter being the full path to the project.yyp file. It will then process the project.yyp file, all the views and object files. If you are trying this on a proper project, make a backup first! :)
 
  • Like
Reactions: JAG

JAG

Member
I can't understand how any teams have managed to make collaborating with GMS2 work. Every time my friend and I work off the same commit whoever commits their work last has an unintuitive, impenetrable mess to deal with that we only ever manage to fix through painful trial and error. It eats up so much time that we could be spending on our game...

Would like to know from staff if there are any plans to address this issue? As it stands unfortunately I can't see myself using GMS2 on another project, and certainly can't recommend it to any other teams.
 

gnysek

Member
I rather doubt that any changes will happen here, as JSON format was decided long ago (2-3 years at least), and they argued several times, there will be no change in it. They were planning to make some params one-line, so they merge easier, but nothing else (and it's yet unknown if it ever happen). I don't expect any promises until they release something.
 

FrostyCat

Redemption Seeker
I have received confirmation from @rwkay to follow-up with tickets and add reproductions. If you have any reproductions, existing tickets or examples of conflict-ridden projects, please PM me to be added to the ongoing conversation between him and I.

Disclosure: Here is the ticket I just filed:
The .yyp file and views directory in the current GMS 2 format is making it impossible to do multi-developer and multi-branch work without risking data loss through manual editing. They keep fighting over what their children are during a merge, even though the group structure has no relevance by compile time.

Attached is a trivial-case example where an identical object was added onto two different branches, dev-a and dev-b, then merged. The zipped file shows the conflicted state (.git directory included) when attempting to merge dev-a into a copy of dev-b (merge-a-into-b). What should have been a trivial merge is now a 2-file conflict, and any mistakes with UUIDs here would cause the object to be dropped.

This has happened on a larger scale with production-level projects, and it is severely hampering GMS 2's suitability for professional use. Please consider fixing this ahead of the Nintendo Switch export's release. A potential solution is listed here: https://forum.yoyogames.com/index.p...git-or-svn-with-gms2.23848/page-2#post-274803
And a copy of the attachment: https://www.dropbox.com/s/ptkt1oo9u4p2q38/MergeConflict.zip?dl=0
 
Last edited:
A

Alwaysusa

Guest
I'm not going to offer any suggestion on how to fix as more knowledgeable devs here have made suggestions , and I'm sure the Yoyo team can figure it out - but I'll add my vote to this system needing an overhaul. I'm not sure how the Yoyo team expect teams to use their software in it's current state (I'm not bitching, I genuinely do not know what work flow is recommended).

Perhaps an interim fix for this would be a help file outlining the known issues and potential ways to circumvent the issues? it might save people (like me), from banging their head against the wall for a few days before realizing that the system has issues. An update to the existing SCM documents at least - noting the problems.
 

Yal

🐧 *penguin noises*
GMC Elder
I saw some discussion about this in another thread a few days ago (thought it was this one, so I didn't bookmark it or anything :/) where someone complained about how the GMS2 projects have metadata files that adjust the order of resources in the resource tree, and two independent people adding new resources WILL lead to a merge conflict, and suggested that they should be removed and GM using folders to order stuff instead (to make it more SCM-friendly). I definitely can't argue with that. I mean, adding more redundant information is just gonna cause more opportunities for information to not be kept up-to-date, as anyone that's ever had to write documentation for an agile project has seen first-hand.
 

FrostyCat

Redemption Seeker
I saw some discussion about this in another thread a few days ago (thought it was this one, so I didn't bookmark it or anything :/) where someone complained about how the GMS2 projects have metadata files that adjust the order of resources in the resource tree, and two independent people adding new resources WILL lead to a merge conflict, and suggested that they should be removed and GM using folders to order stuff instead (to make it more SCM-friendly). I definitely can't argue with that. I mean, adding more redundant information is just gonna cause more opportunities for information to not be kept up-to-date, as anyone that's ever had to write documentation for an agile project has seen first-hand.
I think it's this one from Alwaysusa, which I also responded to.

I genuinely hope that having more professional voices vouching for this would help, and hopefully it turns out well this time. My ticket had been processed last week and its priority reassessed this morning.

Updated: 2018-04-03
 
Last edited:
  • Like
Reactions: Yal

Yal

🐧 *penguin noises*
GMC Elder
I think it's this one from Alwaysusa, which I also responded to.

I genuinely hope that having more professional voices vouching for this would help, and hopefully it turns out well this time. My ticket had been processed last week and its priority reassessed this morning.

Updated: 2018-04-03
I can confirm it's that topic I was thinking about.

I'm not sure if I count as a professional voice yet, but I'm a software engineer using git at work, and I've recently ran into a situation where redundant information in separate files got out of sync, causing issues that wasted a lot of troubleshooting time and irreparably bricked a test device. The issue in my particular case was caused by human error, but I can definitely speak from experience saying that it would be preferably if GM didn't cause similar situations with automatic spread of information/metadata across several files. It makes SCM diffs harder to track and adds nothing but unnecessarily complexity, which invariably leads to problems of some sort or another down the line.
 
  • Like
Reactions: JAG

gnysek

Member
I reported all the problems with SCM and JSON files when public beta came out (it was November 2016 ?), and since that moment, all of the problems are still existing, even when they assured they gonna put some data into one-liners to prevent some of merging conflicts, and do something with comma at end, which leads to problem when two users add new resource at same time at end of resource tree/room layer, but I still see no improvement in that field.
This JSON structure is much worse than XML (at least it didn't have problem with commas at end), and sadly there seems to be many, many not needed informations (I think that's because of PLUGIN SYSTEM, which isn't yet publicity available, but plugins may need some of this info to extend functionality... so lot of data is saved "in case of future use"). Hope they finally gonna do something with it, but I doubt it will be soon (or even at 2.x timeline), as this is BIG change at this point.
 
  • Like
Reactions: Yal

GMWolf

aka fel666
I reported all the problems with SCM and JSON files when public beta came out (it was November 2016 ?), and since that moment, all of the problems are still existing, even when they assured they gonna put some data into one-liners to prevent some of merging conflicts, and do something with comma at end, which leads to problem when two users add new resource at same time at end of resource tree/room layer, but I still see no improvement in that field.
This JSON structure is much worse than XML (at least it didn't have problem with commas at end), and sadly there seems to be many, many not needed informations (I think that's because of PLUGIN SYSTEM, which isn't yet publicity available, but plugins may need some of this info to extend functionality... so lot of data is saved "in case of future use"). Hope they finally gonna do something with it, but I doubt it will be soon (or even at 2.x timeline), as this is BIG change at this point.
I'm still mad they went wo th a central file system.
I mean sure, have a project folder, but then use the files in the file structure.
Also all the .yy files are utterly useless.
Why have a UUID? Files are already unique.
Why have all the extra metadata? Just have it embedded in the GML.
(Maybe make a new language called yygml, that wraps GML with the extra info needed? Like this:
Code:
#script self whatever
{
 //GML goes here.
}
It would make 3rd party editing much more interesting too.
 

gnysek

Member
Also changing layer image name every time you replace image, while it's still same sprite and still have one layer seems to be not the best idea.
 
  • Like
Reactions: Yal

Yal

🐧 *penguin noises*
GMC Elder
Yeah, binary files already take tons of space compared to text files, and not removing them from the repo (and losing the advantage when you only change a bit and most of the data can be unchanged) is just going to waste space... Bitbucket's accounts have limited repo size so this could cause issues with pushes suddenly getting rejected, and the servers at my work keep getting full disks all the time as well (since we're having several daily CI builds)... even though filesize normally isn't an issue, wasting space with no benefit doesn't seem like the optimal idea.
 

GMWolf

aka fel666
Yeah, binary files already take tons of space compared to text files, and not removing them from the repo (and losing the advantage when you only change a bit and most of the data can be unchanged) is just going to waste space... Bitbucket's accounts have limited repo size so this could cause issues with pushes suddenly getting rejected, and the servers at my work keep getting full disks all the time as well (since we're having several daily CI builds)... even though filesize normally isn't an issue, wasting space with no benefit doesn't seem like the optimal idea.
I think its worth pointing ou this is because git makes differential repos.
So it only store line buy line differences, rather than making full backups.

This makes other SCM solutions better for assets, etc, like subversion.
 

Yal

🐧 *penguin noises*
GMC Elder
I think its worth pointing ou this is because git makes differential repos.
So it only store line buy line differences, rather than making full backups.

This makes other SCM solutions better for assets, etc, like subversion.
Yeah, the servers that get full actually are for compiled artefacts, but that's sort of besides the point (the servers get full faster than anticipated because we have lots of redundant stuff because <crap that isn't our fault> happened sometime in the past). I'm pretty sure SVN would fill up a given server disk faster on average ANYWAY because it needs to make a full copy of everything, right? Or did they somehow make it shallow-copy nowadays?
 

GMWolf

aka fel666
Yeah, the servers that get full actually are for compiled artefacts, but that's sort of besides the point (the servers get full faster than anticipated because we have lots of redundant stuff because <crap that isn't our fault> happened sometime in the past). I'm pretty sure SVN would fill up a given server disk faster on average ANYWAY because it needs to make a full copy of everything, right? Or did they somehow make it shallow-copy nowadays?
I don't know. But I wouldnt be surprised if the archives where compressed somehow.
All sorts of smart compression can be used in such a situation.
 

gnysek

Member
I can understand random name of layers, as this helps if you reorder them (for example bottom layer became most-top), so they should have unique name, but replacing image from file, should left at least the merged one with same name (and if image have only one layer, it should also replace content, not name). Then, tracking changes would be easier (some apps, or even scm logs on github/bitbkucket allows to compare changes on images).
I really liked GMS 1.x XML files, as they were easy to read and make external applications, which can extend IDE possibilities (finding orphans, like my GMX cleaner - http://gnysek.pl/en/app.php - sadly not updated since 2012, but still was finding leftovers and unused resources).
 
D

Dene

Guest
Any progress on this? Source-control is really Achilles' heel of GMS2 preventing teams of working on project together. Why that's not fixed already? This issue must have a priority as high as possible.
 
  • Like
Reactions: JAG
G

Gregory Tapper

Guest
Same issue here. Makes it nearly impossible to collaborate in GMS2. :( Please help us, GM dev team!

Easily reproducible...
Create a branch and create an object in the project. Save.
Create a new branch and create another object with another name in the project. Save.
Merge the branches and you'll get a conflict / something like this:

Code:
{
    "id": "079b929a-addd-46af-bdb6-8425ecde4164",
    "modelName": "GMFolder",
    "mvc": "1.1",
    "name": "079b929a-addd-46af-bdb6-8425ecde4164",
    "children": [
<<<<<<< HEAD
        "1766ef89-6303-4b4f-94aa-c16350eb81f7"
=======
        "f0fd4ec1-5917-4a17-9934-a9d3cb73cab7"
>>>>>>> test
    ],
    "filterType": "GMObject",
    "folderName": "objects",
    "isDefaultView": false,
    "localisedFolderName": "ResourceTree_Objects"
}
 
G

Gregory Tapper

Guest
@Mike Do you know the state of this? Is it on the radar? Is there a fix coming in the near future?

Our team is debating using Unity for our next project, but most of us would prefer to use GameMaker <3
 
  • Like
Reactions: JAG

FrostyCat

Redemption Seeker
Any updates on this front? A whole quarter has come and gone since my last report, and the radio silence is disappointing. I'm pretty sure people strong enough to publish on Nintendo consoles would have a use for this, as well as users still affected by any of the many project saving bugs still in GMS 2.
 

gnysek

Member
@FrostyCat By making a quick search, Mike wrote last post on forum on 12th of March, and Russell wrote last post on 25th June. They stopped to write about features/improvements some time ago. I rather don't expect anything new in this topic :(

You can always contact helpdesk about this issue, but the answer will be:
Hi FrostyCat!

Thanks for suggesting this. I've now passed your request on for internal review, so hopefully this will be added in some future release - I can't guarantee this will happen, nor tell you when the change might be implemented, I'm afraid.

Cheers,
Some Guy from YYG
YoYo QA Department
 
K

klarkfromddark

Guest
Hey everyone! Thank you all for describing and adressing this issue so thouroughly.

I'm running a game developer project for drop out adolescents in Norway, and we have been using GameMaker Studio 2 in the beginning as a learning and experimentation tool. Note that I am learning along side them, and I'm still very fresh in coding and development. We are upscaling the development of our projects this fall, as some of our prototypes we're becoming quite fun.

I found this thread after setting up source control for myself - using bitbucket and the GMS2 plugin.

Now I'm wondering how much of a quagmire and dealbreaker this issue is for our sake. To the best of my understanding, we won't run into any issues as long as only one person makes changes to the objects or the instances of objects in any given room - and try to push these at the same time.

Is this correct?

Can we for instance have one person working on the code and creation/editing of objects, one person working on level design by adding existing objects into rooms, and one person working on sprites - and then have them push their commits without this json-missing-comma stuff breaking the project?

Any help would be much appreciated, as we are gonna use educational licences of GMS2, and would commit our project pretty hard going for GMS2 at this point. If we should dump GMS2 all together, we would really like to know sooner rather than later.

Also, I hope the devs come out of radio silence on this matter, as this seems paramount to GMS2s viability as a development tool.
 

FrostyCat

Redemption Seeker
Hey everyone! Thank you all for describing and adressing this issue so thouroughly.

I'm running a game developer project for drop out adolescents in Norway, and we have been using GameMaker Studio 2 in the beginning as a learning and experimentation tool. Note that I am learning along side them, and I'm still very fresh in coding and development. We are upscaling the development of our projects this fall, as some of our prototypes we're becoming quite fun.

I found this thread after setting up source control for myself - using bitbucket and the GMS2 plugin.

Now I'm wondering how much of a quagmire and dealbreaker this issue is for our sake. To the best of my understanding, we won't run into any issues as long as only one person makes changes to the objects or the instances of objects in any given room - and try to push these at the same time.

Is this correct?

Can we for instance have one person working on the code and creation/editing of objects, one person working on level design by adding existing objects into rooms, and one person working on sprites - and then have them push their commits without this json-missing-comma stuff breaking the project?

Any help would be much appreciated, as we are gonna use educational licences of GMS2, and would commit our project pretty hard going for GMS2 at this point. If we should dump GMS2 all together, we would really like to know sooner rather than later.

Also, I hope the devs come out of radio silence on this matter, as this seems paramount to GMS2s viability as a development tool.
I'm not so sure that the developers would come out of radio silence on this matter for you, given that they haven't come out of radio silence for me. My ticket #0029196 has languished for months, and all YoYo thinks the problem deserves is a brief, nebulous mention on the Roadmap.

But like the last time this happened in GMS 1.x, I will help to the best of my ability, as a community member.

The JSON-missing comma problem can be resolved by installing git-json-merge and patching your projects, as described here. This isn't just an issue for GMS 2 in particular, it's an issue whereever JSON is part of a source-controlled project in any language.

As for the workflow, the single-branch-single-contributor workflow is guaranteed to be safe. I use this one regularly.

As far as my investigation can discern, the conflicts described in this topic mostly come from adding and removing resources. So perhaps you can avoid (or at least minimize) conflicts by having only one member add/remove, and all other members do editing only. Whoever does the code would also add placeholders for levels and sprites, and push those to the origin. Then the level designer and sprite would pull, replace the placeholders with actual content, then push back the changes.

Try out the workflow above on a dummy project and let me know how well it works.
 

Carbon

Member
Wow 2019 is coming yet we're still face-palming over this crap? I remember this was huge back when GM was just recently out of beta, early mid 2017. But hey, really, nothing has happened since? o_O

Any update on the current situation?
 

Jack S

Member
Your primary issue is poor communication and bad GIT habits.

I run a team with a dozen devs using GMS and GIT and while we do occasionally have a merge conflict it's almost always our fault.

1. Get and use slack / discord / whatever that lets you talk in real time.
2. When someone is going to make a change that will affect the project file (add, delete, organize the project tree, etc) you need to follow a very specific pattern. Pull to latest. Then make your changes. Then push your changes. Then have the team pull your changes right away. This will solve 99% of merge conflicts with the project file. It's all about communication and making sure people don't edit an older version of the project file than the current point version.
3. Most other files won't have conflicts unless you happen to change the same object someone else changed before syncing the code up.
 

GMWolf

aka fel666
Your primary issue is poor communication and bad GIT habits.

I run a team with a dozen devs using GMS and GIT and while we do occasionally have a merge conflict it's almost always our fault.

1. Get and use slack / discord / whatever that lets you talk in real time.
2. When someone is going to make a change that will affect the project file (add, delete, organize the project tree, etc) you need to follow a very specific pattern. Pull to latest. Then make your changes. Then push your changes. Then have the team pull your changes right away. This will solve 99% of merge conflicts with the project file. It's all about communication and making sure people don't edit an older version of the project file than the current point version.
3. Most other files won't have conflicts unless you happen to change the same object someone else changed before syncing the code up.
So why use git? If you are going to do that, then just used a shared file... Smh.

As it stands, two people cannot work simultaneously, and that is a problem.
It isn't the users not using, is an issue with the product itself.
 

Jack S

Member
So why use git? If you are going to do that, then just used a shared file... Smh.

As it stands, two people cannot work simultaneously, and that is a problem.
It isn't the users not using, is an issue with the product itself.
I have a dozen people working simultaneously being smart about it. Any version control system will blow up in your face if you aren't smart with it. In this case you have to be aware that the project file is bull💩💩💩💩 and treat it smartly. Designate one person on your team to add objects and prettify the organization, anything you want put some proccess in place. This is just life with project files - VS, XCODE, and even Unity (marginally less so recently) have this issue. It's a matter of organizing and managing your team and using proper development patterns.

This is a case of yes it would be nice if you could have a bunch of randos doing any random thing they want to the project and structure without thought or care - but that will NEVER happen.... not even in a straight code environment like web development. =)
 

GMWolf

aka fel666
I have a dozen people working simultaneously being smart about it. Any version control system will blow up in your face if you aren't smart with it. In this case you have to be aware that the project file is bull**** and treat it smartly. Designate one person on your team to add objects and prettify the organization, anything you want put some proccess in place. This is just life with project files - VS, XCODE, and even Unity (marginally less so recently) have this issue. It's a matter of organizing and managing your team and using proper development patterns.

This is a case of yes it would be nice if you could have a bunch of randos doing any random thing they want to the project and structure without thought or care - but that will NEVER happen.... not even in a straight code environment like web development. =)
But why should we put up with it, when there is a really simple fix that could likely be implemented in a matter of minutes (adding a dummy entry is not a difficult thing to do).


Should we ignore all issues with GM simply because there is a workaround?
 

Jack S

Member
But why should we put up with it, when there is a really simple fix that could likely be implemented in a matter of minutes (adding a dummy entry is not a difficult thing to do).


Should we ignore all issues with GM simply because there is a workaround?
I'd honestly just settle for a tool that rebuilds a project file from the project folder by scanning it. But yes improving the reliability of the project file isn't a bad thing. That's not an excuse for people expecting magic out of source control, you still gotta be smart with it.
 

GMWolf

aka fel666
I'd honestly just settle for a tool that rebuilds a project file from the project folder by scanning it. But yes improving the reliability of the project file isn't a bad thing. That's not an excuse for people expecting magic out of source control, you still gotta be smart with it.
but why? all we need is a dummy object!

that being said, file system based projects are 100% better than central file system projects, that would have been by far the superior option.
 

JAG

Member
Yeah I definitely agree with @GMWolf here, your comment
Your primary issue is poor communication and bad GIT habits.
is misguided imo. The "project file" is an internal GM implementation detail; this method of tracking resources works well enough typically (it is what it is) but GM users definitely shouldn't ever need to interact with it directly, especially as a result of something as fundamental and pervasive as source control use.

The simple reality is that if two new completely unrelated objects are added on separate git branches, those branches should be able to automatically merge without conflict. The suggestion to
Designate one person on your team to add objects and prettify the organization, anything you want put some proccess in place.
doesn't strike me as "being smart about it" so much as it sounds like precious dev cycles being wasted jumping through hoops to work around a really 💩💩💩💩ty GameMaker bug. I understand there is no other option currently, and kudos to you for figuring out a way to make it work, but for many of us we have so little time to work on our projects that just dealing with this as it is is not a great option.

We should certainly be patient and understanding with YoYo Games, but as paying GM users we're also not obligated to ignore it if it's a pain in our asses (which it definitely is in mine).
 

gnysek

Member
Your primary issue is poor communication and bad GIT habits.
You will always get conflict in JSON when two people adds new resource at end of tree (if not in GIT then in GMS which cannot read this file then), so it's not a bad GIT habit. XML in 1.4 was much better and got no problems with it, YAML would also be better as it have no commas at end.
 
  • Like
Reactions: JAG

Stephane

Member
We've been using Smart Git for over a year now and have only run into small issues here and there (some of them seem like big issues at the time). As it's been said before, make sure you have strict rules around how your repo is managed and you will be fine.
 

Jack S

Member
You will always get conflict in JSON when two people adds new resource at end of tree (if not in GIT then in GMS which cannot read this file then), so it's not a bad GIT habit. XML in 1.4 was much better and got no problems with it, YAML would also be better as it have no commas at end.
I understand the frustration. This is why I say the simple quick solution is give GMS the ability to regenerate its project file by scanning the project folder. This won't cause yoyo to rework the IDE / spend a ton of time. It will make these annoyances recoverable. I do agree the xml was better to merge - they even have a solution really - it wouldn't be that hard to keep the project file internally as json and export and load it as xml.

However what is, is. This isn't going to change any time soon - as devs we limited choices. Complain. Offer suggestions for improvements. Find a workflow that works. Move to a different platform. ....

I'm going with "Find a workflow that works." Which doesn't impede asking for and suggesting improvements to the base system. (Not just complain that it sucks.) What we have now works, and no it's not much overhead on a team to use good source control habits.

Personally what a lot of people describe here is in my opinion an abuse of branching. Generally you shouldn't have each developer working in seperate branches and trying to do mega merges when features are done. That's begging for conflicts. A much better branching strategy is having a production and a development branch. Production only pulls from development and you don't wind up with the merge issues because you don't do new changes in both branches.

The long and short of it tho is you have an option to be productive and have things work well - the question is will you use it or continue to fight against the way the system works.
 

JAG

Member
@Jack S Im with you mostly here, I think you are right to say we should work with what we have while also suggesting improvements to the system, and I think your idea to "regenerate its project file by scanning the project folder" would work perfectly!

I do think though that your description of "good source control habits" is inaccurate and could be misleading to new developers, and additionally kind of serves to let YoYo off the hook undeservedly. One of the core benefits of source control is the ability for multiple devs to be working in separate branches simultaneously. When features are unrelated these branches should be able to be merged into master without conflict. If the changes ARE related (ie two devs modify the same line of code) THEN a merge conflict should arise and require resolution (this happens all the time in enterprise software, and is totally expected and reasonable). Like I mentioned previously, git conflicts should not arise from two devs modifying completely unrelated code in a GM project; the resource tree mutations are not something we as devs should ever have to think about.

Anyway what I consider important here is that we don't place the burden on developers to work around a very clear shortcoming of GM. I think we need to stay on-message, and imo the message is "Hey YoYo please fix this it's terrible!"
 

gnysek

Member
In GM 1.x tree changes were merged without problems in lot of cases (the problem arises when both reorder of groups and new resource are added in one commit, while another dev added/deleted something).

Generally, tree should autogenerate, and user sould only choose a global sorting method in tree on project (alphabetically or by modification time, but maybe only alphabetically). If you want another order, I don't see a problem with naming groups like "01_main_objects", "02_obstacles", "03_interactives", etc :) That would solve LOT of problems.
 
Top