• Hey! Guest! The 39th GMC Jam will take place between November 26th, 12:00 UTC and November 30th, 12:00 UTC. Why not join in! Click here to find out more!
  • 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 Is it safe to put non resource files into the folder structure

J

jessieweidig

Guest
Hi!

I was wondering if it is safe to put your non-resource files into the project folder structure, maybe under your own sub directories. I mean things like your Pyxel Edit files, mockups, project plan, etc.

Thanks! :)
 
  • Like
Reactions: xot

Nocturne

Friendly Tyrant
Forum Staff
Admin
Moderator
Yes, it should be. The only problem would be if you then save the project under another name, or if you use the built in source control (which will be available at launch, but isn't in the beta). The internal source contrl won't pick up those files if they are changed, and saving under another name will create a whole now folder (and sub folders) for the renamed project, so the extra folders you add will be in the old save location. However, GMS shouldn't interact in any way with folders within the project that are not actually created by GMS (I have a few extra folders in my projects folder for things like screenshots and promo material and have not seen any issues) .
 
  • Like
Reactions: xot

gnysek

Member
Then how internal source control works, if it don't pick those files by "git status" ? Interesting...
 

GMWolf

aka fel666
Then how internal source control works, if it don't pick those files by "git status" ? Interesting...
I assume GM only adds files that are tracked by the IDE, rather then scanning directories.

I hope source control will be better than it was in gms 1.4. It working would be nice, and Simple things like adding a file to be tracked should really be done automatically...
 

gnysek

Member
Seeing how data is stored in .yy files, it's rather "backup" than real source control, cause:
  • because of JSON, adding a new resource changes two lines in resource tree list ( comma need to be added on last line), instead of only new one
  • because sprite frame names are random GUID, replacing frames deletes old sprite and create a new one with totally different name, so source control won't track frames history
  • because main .yyp file in some way duplicates data from resource .yy files, when you change order of something in tree or add a new resource, or even new resource tree view, and another person in your team do one of those at same time, you will have unsolvable conflict, since there will be one million new entries in project.yyp file instead only references to them:
  • gms2_git.png
  • doing something in another branch and merging it into master is impossible because of file structure in GMS2.
So, working with more than one person, or having more than one branch can make your project a s-hit you will be dealing to solve for several hours in just one commit. It's the biggest fail in GM:S2 in fact.
 
Last edited:

GMWolf

aka fel666
Seeing how data is stored in .yy files, it's rather "backup" than real source control, cause:
  • because of JSON, adding a new resource changes two lines in resource tree list ( comma need to be added on last line), instead of only new one
  • because sprite frame names are random GUID, replacing frames deletes old sprite and create a new one with totally different name, so source control won't track frames history
  • because main .yyp file in some way duplicates data from resource .yy files, when you change order of something in tree or add a new resource, or even new resource tree view, and another person in your team do one of those at same time, you will have unsolvable conflict, since there will be one million new entries in project.yyp file instead only references to them:
  • View attachment 4869
  • doing something in another branch and merging it into master is impossible because of file structure in GMS2.
So, working with more than one person, or having more than one branch can make your project a s-hit you will be dealing to solve for several hours in just one commit. It's the biggest fail in GM:S2 in fact.
Let's hope GM's built in git interface will somehow fix this. No idea how they would do it though...
 

gnysek

Member
Let's hope GM's built in git interface will somehow fix this. No idea how they would do it though...
There's no way it will fix it. There must be some pre-processor to it, but it's too complicated in my opinion, so it would be easier and faster to change file structure. I gave some proposals on private chat, but Russell and Mike doesn't seem interested - maybe they have another ideas, or don't see a problem yet.
 

GMWolf

aka fel666
There's no way it will fix it. There must be some pre-processor to it, but it's too complicated in my opinion, so it would be easier and faster to change file structure. I gave some proposals on private chat, but Russell and Mike doesn't seem interested - maybe they have another ideas, or don't see a problem yet.
It wouldn't surprise me if they just keep things as they are an let us deal with the problems ^^
 
  • Like
Reactions: Yal

Yal

šŸ§ *penguin noises*
GMC Elder
Seeing how data is stored in .yy files, it's rather "backup" than real source control, cause:
  • because of JSON, adding a new resource changes two lines in resource tree list ( comma need to be added on last line), instead of only new one
  • because sprite frame names are random GUID, replacing frames deletes old sprite and create a new one with totally different name, so source control won't track frames history
  • because main .yyp file in some way duplicates data from resource .yy files, when you change order of something in tree or add a new resource, or even new resource tree view, and another person in your team do one of those at same time, you will have unsolvable conflict, since there will be one million new entries in project.yyp file instead only references to them:
  • View attachment 4869
  • doing something in another branch and merging it into master is impossible because of file structure in GMS2.
So, working with more than one person, or having more than one branch can make your project a s-hit you will be dealing to solve for several hours in just one commit. It's the biggest fail in GM:S2 in fact.
^this. Sure, being able to use it for backup is a good, but GM's weakness has always been really bad team features... and this doesn't really make it more stable in team projects.
 

AnonyMouse

Member
Just to remind that if "Enable back up on save" or on debug/run/create are enabled GMS will copy them too. I put about a GB in the folder and then was impressed all of the stuff is backed up when press F5...
 
D

Diabolo

Guest
because main .yyp file in some way duplicates data from resource .yy files, when you change order of something in tree or add a new resource, or even new resource tree view, and another person in your team do one of those at same time, you will have unsolvable conflict, since there will be one million new entries in project.yyp file instead only references to them:
If you change the order of resources in the tree it doesn't affect the main .yyp file, unless you've added a new folder/group to the project in the process - resource ordering information is stored in folder resources. However, adding a custom resource tree view does add a whole bunch of new folder resources to the project, iirc.

Ignoring "room_order" (which is obsolete and should be removed) and "script_order" (which shouldn't be necessary), the only duplicate data between the .yyp and .yy files should be that the "Key" of any given resource in the .yyp is the same as the "id" in the .yy file and that the "resourceType" in the .yyp happens to match the "modelName" in the .yy.

The block of information added to the .yyp for a new resource tells us what a resource is and what's required to load all its data. Because most of that block tends to be the same between various resources (as it stands) it does cause source control conflicts, but for just one resource it's trivial to solve the conflict - "use text block from 'theirs' before 'mine'" does the trick. However, I've not tried anything more complicated and even having to resolve this type of conflict alone is not ideal (I know what the end result should be...).
 
I personally would keep editable Assets outside the Source folder just to be safe, my projects are structured like,

Code:
/GameName/
        /Assets/
              /Artwork/
              /Graphics/
              /Audio/
              /Animations/
              /Documents/
              /Certificates/
              /Fonts/
              /Screenshots/
              /Video/
       /Source/
             GameName.gmx
             Archive.bat  ; a little script to zip up current project state into the "Archive" folder
       /Builds/
             executables go here per platform or app store
       /Archive/
             archived zip files with datetime go here of previous versions
I'd also like to complain how the <GameName> is still not determined somewhere in the Global Game Settings and based off gmx project filename. Meaning if you decide to change the filename later on for whatever reason, you will make the appdata and all the previous stored files useless. Especially a problem if your game has already shipped.
 
Top