thats terrible Ragnar~~
I saw on the google doc you put up earlier that you guys arent testing (STATUS UNKNOWN) on linux right?
I have been working on defold almost everyday, and I use windows and linux all the time (most linux, like 70% of the time) so I could fill that part in~~~
I almost sure I won’t go back to the old editor because of the online dependency aspect of it… XD
3 Likes
I really appreciate that and thanks for your concern! We will test on all platforms during next week but it would be great with further testing help. I’m pretty confident most of the app will run equally well on every platform with the exception of:
- The launcher - a cpp program that boots the app and handles rebooting from downloaded updates
- Graphics - driver dependent but it’s basically the same OpenGL features as the current editor
- Native libraries - e.g. simulating particlefx, but also same approach as current editor in this regard
And then we have Windows where I bet we will have one or more issues with back-slashed paths, the registry and possibly different access/admin rights etc. 
Anyway, I will keep the doc updated with status as we know more.
Edit: Yesterday I added the linux 64 target to the CI system, and obtained the world’s first binary of Editor2 for linux64. And it f*cking worked for all the bullets mentioned above. I have never seen that before and it tells me that we are in for something really aweful that we have yet not seen. Software dev is never this easy. I should also add that a few issues prevented me from thorough testing (like actually running a game), so the story is not over. Looking good so far though!
Edit2: The system I tested on was Ubuntu 64 on a new Dell laptop, so to say that it “works for linux64” is clearly an overstatement. 
11 Likes
Awesome, cannot wait to try this Editor out. This Friday, you say :))
3 Likes
We had a meeting yesterday, one of the things brought up was that we need to be better at “expectation management”, and I’m the first to admit I’m not really good at that. 
It’s hard when you get really excited about stuff, like mr. Molyneux. Anyway, it’s great that you want to try it out! Just be aware that there is a lot left to do on it, quite rough around the edges so to speak.
6 Likes
So… Should we expect to use the new editor Friday, rough edges and all… or not? Here’s your big chance to manage my expectations ;p
3 Likes
Will the new editor have any of these debugging features?
-
Set breakpoints before/during debugging
-
Step in/over/out
-
Run to cursor, break and continue
-
Review call stack
-
Inspect/modify variables
3 Likes
As I wrote in the original post regarding this friday, the purpose is to get help testing and finding issues. For that reason it will not be open to everyone yet, to avoid misunderstandings of what it’s supposed to be and what the status is.
1 Like
Yes, but not for pretty long. You will still need to use ZeroBrane to have that functionality.
1 Like
We are now finally at a point where it makes sense to start the external testing phase. If you want to help out, we would greatly appreciate it. If so, send me a PM and I will give further instructions. There are still plenty of issues to fix and we hope you will find and report even more.
Some things to note:
- It’s not ready for efficient usage and production purposes
- Editor2 will send errors to sentry.io, without asking for permissions (not implemented yet)
- It helps if you are comfortable with git, or avoid pushing to your repository (data could be broken)
- It’s 100% compatible with Editor1, but bugs might make that statement temporarily false
A rough outline of the plan forward is:
- Fix issues
- Implement remaining features that we have in Editor1
- Release it for real
- Work on UX/workflow improvements
- Start working on larger new features
14 Likes
When do we join the Editor 2.0 party?
3 Likes
Hi. Out of curiosity: Will there be any way I can use Vim key bindings in the awesome-autocomplete-editor? Would be sad if I’d have to work in Atom to keep my muscle memory’s sanity and skip the autocomplete goodies.
1 Like
Hi! Right now the bindings are emacs/sublime-ish. Eventually we will support custom bindings but we haven’t decided to what extent. Vim with its modes is more of a challenge
1 Like
Cool. I’ve been thinking…
Actually, a more scalable solution for this problem would be to be able to use Defold’s autocomplete engine in any arbitrary text editor. That could be achieved by either decoupling the autocomplete engine from the Defold editor to be used as a library in whatever text editor plugin people might implement, either by implementing an API (localhost-bound HTTP or something) for a text editor plugin interfacing with the defold editor (kinda like how omnisharp-atom interfaces with an intellisense server).
I’m honestly willing to take up the project of implementing an autocomplete plugin for Atom if provided with an interface to Defold editor’s autocomplete engine.
Disclaimer: I in no way endorse trying to write Unity C# with omnisharp-atom. It’s a buggy, over-extending piece of crap that isn’t even working anymore.
2 Likes
I’d like to share a workaround about windows version of editor.
On weak systems (old notebooks and office-like pc-s) editor sometimes could not start, showing only a console window for a few milliseconds and then halting with an error :
Error occurred during initialization of VM
could not reserve enough space for 1433600KB object heap
The problem is: Java heap size used in default config.
If so, you can manually change the following line in Config file:
vmargs = -Xms1024m,-Xmx1400m,
This is a initial heap size (Xms) and maximum heap size (Xmx) in megabytes.
So, if your system have not enough free memory, java VM cannot run.
you can decrease this values to meet your system requirements.
for example:
vmargs = -Xms512m,-Xmx1024m,
3 Likes
Sounds like a fun and ambitious project
Our autocomplete engine is really nothing magical and we can’t prioritise creating a service out of it right now. Roughly what we do is parse any require’d modules (using antlr, I think the example Lua grammar will be fine) building a namespace/symbol table and then augmenting that with our built in functions.
Current info on our built in functions is published with every build. For info on how to fetch and parse it, have a look at @britzl dash-docset project https://github.com/britzl/Dash-User-Contributions/tree/master/docsets/Defold - in particular createdocset.py. @Lukas_Palmer made some notes about using Atom with Defold a while ago Big List of Lua Resources!, that might help.
2 Likes
Cool, thanks. I took an eye. Your docs seem more than parseable. 
It’ll make for a good side project. Maybe I’ll begin with a generic autocomplete-lua plugin and add Defold support to it. I found this lua AST parser for JS, so it seems like a doable project.
2 Likes
If you are looking for Defold support in Atom then please check this post: Defold docset for Dash
2 Likes
Thanks. Snippets are cool, but building a smarter autocomplete is better and more fun as a project.
3 Likes