Can somebody explain the new "save as"?

How do I...?
1

As of today Gdevelop added an extra step to saving, with the options of “keep the new project linked to this game” and “start a new game from this project” I’ve tried both versions in the current game folder as well as a new folder and can’t tell what the difference is. What is this extra step doing? (and what is the thought behind changing our project name in our settings every time we want to save a version?

my workflow: My save file name indicates my project and version and a note. So i’m currently on gameshow1.2.206SCORELINK.json.

Save-as i would name it something like gameshow1.2.207SAVETEST.json and move on.

Now, after some testing what the options do, I could still name my json as I pleased, but ended up with my project setting changed to “gameshow - copy -copy -copy -copy”

With these changes to gdevelop, I’m now clearly using it not as designed. How should i be saving file iterations? What is the ideal workflow the devs are trying to get us to use? Or is this all just convolutions of local saves in order to keep some kind of parity with the cloud?

2

I believe the new choices in Save As are the result of a feature request. People may have a completed project and want to use it as the foundation for a new game. Previously, saving it in a different location, with a different game name etc, would still keep it linked to the original project. Then if you tried to publish your new game on GD games for example, it would replace the game you already had published.

Or so I’ve gathered from some post topics I have come across.

So this would seem to be a very nice solution.

3

so… that’s potentially scary. so now json files might be linked to a project other than the folder they are in?

4

and… i’ve never saved into a new folder and had the project link to a different directory. What platform would that happen on?

5

Any of them.

My understanding is that the project was linked with GDevelop management stats and were registration based and not folder/location based.

This change ensures that you can break that link.

6

I made a new folder, copied over parts of a project, copied over a json and renamed it “randomjson.json”. I opened the randomjson.json file in gdevelop, and as expected it saw the files in the new folder and the things i didn’t copy over were missing. I guess the link with gdevelop and all the phoning home it does is what changes when you break that link.

But… the question still remains. With this system in place, what is the correct procedure for saving version changes? Do i really need to look up what my last saved file was before i enter my save as dialog to avoid having -copy-copy-copy-copy in my project name?

7

I’m am unclear what you are referring to as far as version changes, generally you would back up the entire project folder for that, the json alone isn’t going to do anything for you by itself.

The most efficient way to keep your project revisions backed up would probably be a github account and github desktop, and pushing your large revisions as described here: How to backup and maintain your project using GitHub and GitHub Desktop - GDevelop documentation

Otherwise, use the new save as dialogue, remove the -copy from the project name, and choose a folder to save it to. Keeping it linked will only matter if it is using gdevelop stats, and if it isn’t it won’t matter which option you have selected.

Edit: I’m also unclear if your workflow means you are saving into the same folder as your main project. You should generally avoid using save-as to save into the same folder, basically ever. Especially if you are using multiple file mode for larger projects, the save as function will only change the name of the main json, not any resources or other files, so changes to those will override old versions.

8

Since I’ve done this probably 7 thousand times in the last 5 years without any issues, I don’t understand how it is a bad idea. All I want is to save a new json of my recent changes. If you save as into your working folder it doesn’t touch your resources, it just creates a new json - which is exactly what I want/need. This new change still does that, only now i have to work around gdevelop wanting to control the name of my save file on every save because of a feature that most people would only rarely use.

Years ago, I lost about a month’s work on two gdevelop projects due to corrupted jsons. It was many versions ago, but I cant afford to trust that my latest save file is all I need.

I guess i’ll try github. I usually work offline (or worse, on dummy lans), so its really clunky for that. It seems very non-gdevelop to have to resort to git just to have a version history.

9

Every time you want to experiment with something, or want to save off a version because you aren’t sure you like a new version better, you create an entire copy of your whole project, including all your assets?

10

Just to clarify, this is actually problem I’m referring to in regards to resources.

Let’s say you are using a bitmap font, and a few weeks later realize the native resolution you exported the font at is too small, so you replace the resource with a re-exported Bitmap font. Then you realize even later you need to go back to the version from weeks back.

If you go back to that original version, the resources don’t go back to that version, so now all of your object placement and positioning events that deal with that bitmap font are incorrect as the original resource size doesn’t exist anymore.

No, everytime I experiment with something I explicitly do not save my changes, especially as an autosave file is created upon preview.

If I was doing offline backups only, then yes I would absolutely be backing up the project folder every time I do a major change, including resources.

As mentioned above, in my case I use github so I don’t really have to worry about either.

To be clear, the github stuff was just a recommendation. If you want to continue to use save as into the same folder, so long as you’re connected with the above risk you can absolutely keep doing so. Also I think in your existing workflow, you’d be best off to just update the “-copy” In the save as dialogue to whatever date you want. It’ll transfer that to the json filename.

11

That all makes sense. Thanks for talking me through it. I’m giving github desktop a go. It appears it isn’t as unfriendly offline as I thought. Its going to be a scary learning curve to change how/where/why I save files. I’d rather put my limited brain power into solving issues in the game instead, but this does seem like a better workflow if/when i get used to it. Thanks.

1 Like
12

I use Git but I don’t use GitHub (for non shared things). First install Git for your system. Then create a directory where you want to host your repository, for instance a directory named ProjectRepos. This can be a directory on your system, or on a USB drive, or whatever. Inside ProjectRepos, create a directory called project-name.git.

Change directory into project-name.git using your system’s terminal emulator, for example GitBash for Windows, or regular terminal on Linux/Mac. Now issue the command git init --bare (if you are using a file system that does not support permissions, such as one of the fat family which I use on a USB so I can move between different operating systems, or if you will only be working on the project on one machine) or git init --bare --shared=all (if you will be using a file system that supports permissions and also will be moving the USB between different machines). You have now created a bare repository to host your project repo in.

Now you can change directory to where you work on your projects. For example say all your projects are in Documents/GDevelopProjects, go into that directory. Now issue the command git clone path/to/bare/repo. This will create a new directory called my-project instead of my-project.git, and will also give you a warning that you appeared to clone an empty repository. Now copy your project from the directory you were working on it in (if you had already been working on one) or (more usual) begin your new project directly in this directory. There are other ways to do this but this way is most simple for me to explain in text.

From now on you will use this directory for your working on your project.

So first thing first, if you have not set up a global user name or email in Git config you will issue the commands git config --global user.name "Your Name" and git config --global user.email "youremail@youremail.address".The --global tag is optional, you can leave it out if you would rather create a local user name and email per project/directory which is handy when different projects require different username/email.

Now that Git will know who you are so it can keep track of the author of changes, you will stage the project you have copied into/saved from a new project into this directory. There are a couple ways to do this but for the general purpose you will probably use the command git add -A. Then you may commit them with a message git commit -m "Look ma I made a repo!" and now push the changes into your bare repo with git push origin master (assuming master is the name of your main branch, you can call it something else if you prefer.)

Now your bare repo is caught up with all the work you have done in your work space directory. Every time you make changes you are happy with, you can save your GDevelop project and then stage, commit, push.

Now lets say you want to try something out in your project and you aren’t sure it will work. In GDevelop, make the changes and save the project. In your working directory (you always only work in your working directory, not in your bare repo), you can get out of the master branch (that is perfect and you don’t want to mess up), and start working in this new testing branch. In fact you will probably never work directly on your master branch. So issue the command git checkout -b working , where “working” is just whatever you want to call the branch you are doing your work in. Now stage, commit and push the changes you had saved in GDevelop that you don’t want contaminating your master branch. The steps are mostly the same. git add -A , git commit -m "First commit of new changes" but on the push command, since this is the very first time you’ve created the branch named ‘working’ (by checking it out), do the command git push -u origin working. After this, any time you are in the branch named ‘working’ and want to push (after you have staged/commit), you may just git push with no other instructions and it will push to the branch named ‘working’ in your bare repo. Also, you only use git checkout -b nameofbranch the first time you are creating the branch you are checking out. After that if you had switched back to master branch with git checkout master and want to go back to the branch named working you would use git checkout working.

Mkay now continue working and saving in GDevelop. If you are happy to your changes you may stage/commit/push the branch to the branch on your bare repo. If you dislike the changes but have already Saved in GDevelop, you may git status and look at the changes you have saved in GDevelop but not yet staged for commit, and pick out what you are not happy with and git restore filename to discard the unstaged changes in working branch. Then refresh your GDevelop session by going to File/Open/Recent/ThisProjectOpenRightNow. GDevelop is refreshed and you will see the changes you discarded with git restore command are gone.

Ok so you are happy with all the test changes and want to put them all in your perfect working branch. Maybe you are so happy that you decide to change the version number and save in GDevelop and merge as a publishable update! So in working branch still, run git status. Make sure that you have staged/commit/pushed (-m “Version 1.9.0”) your final changes to working branch. git status should report ‘nothing to commit, working tree clean’. Good now git checkout master. Again double check with git status to see that master in your working directory is same as master in your bare repo with nothing to commit, working tree clean, and not ahead of master by any commits. Now git merge working. Perfect! Now you can checkout branch working again and get started on something else.

But what if you’ve made a lot of changes and even pushed them to your bare repo, on whatever branch, and now you realize you need to scrap a lot of these changes and get the project back into the state of a previous commit? git log --oneline will show a list of commits. Pick the commit that comes after what you want to revert to, so if you want to revert to commit 3, select the hash for commit 4 and run git revert --no-edit hash. The --no-edit is optional and will just commit your reversion with the default message, but I include it because you might have a really confusing and complex default editor on your system like nano and you are probably too lazy to figure out how to change it to vi, so you just want to avoid writing a message on your revert because you can’t even figure out how to move around in nano without writing jjjjj or 5 G all over the place. Now after that just git push and your working directory and bare repo are back to where you want them. There is an interesting difference between git revert and git reset which you can learn more about if you like.

Anyway Git is really simple and has a lot more that I have not touched on.