Discontinuing Editor 1 & Migrating to Editor 2

Announcements
#1

editor%20switch
editor switch.jpg1483×665 282 KB

The transitioning to Editor 2 is coming to an end. We feel that Editor 2 is on par with, or better than, Editor 1 and has been for quite a while, and the vast majority of our users have already switched. Therefore we feel it is time to discontinue the old Editor 1*.

(* We use the names “Editor 1” and “Editor 2” to separate between the two editor frontends. The engine versions are the same between the two so Defold 1.2.128 can be run with both “Editor 1” and “Editor 2”, for instance)

How to switch to the new editor

  • Make sure that you sync your projects so that all your local changes are uploaded to the Defold cloud git servers.
  • Download and install the new editor.
  • Start the editor and select “Import project”.
  • After logging in, select your project from the list and a directory where your local copy will be stored.
  • When the editor has opened the project, select Build and run.

DONE! You can now continue working with your game in the new editor and sync your changes as usual. The interface of the editor is a bit different but should not take long to get used to.

What can possibly go wrong?

If your project contains files that has not been edited in a while, chances are that we have updated the file format for that file type with new fields. Opening an old project in Editor 2 and saving it (Editor 2 saves all project files) may therefore create lots of diffs even though you do no edits. This is normal.

We promise 100% compatibility between the editors so you are able to work with them in parallell. If you hit a bug where your project opens and works in Editor 1 but not in Editor 2, file a bug immediately. You can also post on the forum and we will help you.

Known issues

But I still see old stuff on the site

Revising all documentation takes time but will certainly be done. You can help make the required updates faster by:

  1. Select the text that should be changed and press the “Have a suggestion?” button at the bottom right corner in the browser.
  2. Post pull requests to our Github documentation repo.
16 Likes
#4
#5

… Is there any way to disable the auto-indenting feature in Editor 2? That one is the one thing that keeps annoying the hell out of me :frowning:

1 Like
#6

Request it here https://github.com/defold/editor2-issues/issues

1 Like
#8

I switched to Editor 2 and was hit by a data loss issue (reported here) because I had my script editor, Atom, opened when I was attempting to sync. The response to my issue implied that this isn’t something that will be fixed. Is that the case? I prefer using Atom over the builtin editor, and I am sure I will forget to close Atom before syncing again in the future…

Seems a bit of a shame, since I have been using Editor 1 without issues like this for a long time!

2 Likes
#9

What I would suggest is to not use the built in git sync features of the editor, only use it as a visual aid to see what has been changed since last commit. Instead use a tool like sourcetree to do commits and sync.

2 Likes
#10

Closing Atom while syncing is not a solution we’re particularly happy about :slight_smile:
The problem is caused by Atom’s file locking behavior on Windows vs. jgit apparently assuming it’s the only process accessing the files. Right now we’re hoping a newer version of jgit will be less flaky. If we had more time we’d probably look into contributing/fixing it ourselves, or abandoning jgit completely and using native git client - which would bring it’s own set of issues. But, well, we’re spread pretty thin.

3 Likes
#11

I have no idea what goes on under the hood, so that explanation helps make of sense of things. I also agree that other issues should be prioritised given what you’ve said. I should probably do something like what Pkeod is suggesting - but I am a perennial noob and New Things™ scare me so we’ll see how I fare… :slight_smile:

On a serious note, I would say that most people of my technical level would probably assume that the built-in git sync functionality is safe to use so it’s no doubt something to return to later if jgit doesn’t sort itself out!

7 Likes
#12

Completely agree that the built in git support should be safe to use, and we definitely want to fix this.

6 Likes