I’m running Ubuntu 18.04 (our supported platform) in a VM.
I haven’t had any success with any of the MESA_GL_VERSION_OVERRIDE related flags (I still get the jogamp issues). But hopefully, if I can get that to work, it should also behave the same way it does for you.
Side note: We’re very eager to switch to LWJGL instead of JOGL. Especially considering that they have a Vulkan/MoltenVK backend which will help on macOS.
Actually I had no issues with Defold at all when I was using Ubuntu 18.04. I didn’t have to mess with MESA overrides. My problems started with Ubuntu 20.04.
Fun Fact: The publisher of FSH / FSD is Puppygames/Cprince, the founder of LWJGL. 
Aha, nice!
Ok, so you don’t use any extra variables to launch Defold on Ubuntu 20.04?
In 1.2.179, you launched the editor like so?
$ ./Defold
I think I misunderstood your comment on the MESA override then.
Which makes sense since it seems it’s something else stopping the engine from running properly.
Prior to 1.2.180 (1.2.179 and older) I used to run this:
export MESA_GL_VERSION_OVERRIDE=2.1
./Defold
I had for 1.2.180 because of your guidance only used ./Defold
I’ve updated engine today and since this time Defold crashes when I open GUI files in editor. The graphical shell of OS hangs.
My computer’s OS: Ubuntu 20.04
If I can be helpful, I’ll describe my scenario.
I’m running Steam version of Defold(1.2.180) on my laptop(intel+nvidia graphics, Manjaro linux).
Without launch options and with “MESA_GL_VERSION_OVERRIDE=3.3 %command%” I got
java.lang.ClassCastException: class jogamp.opengl.es1.GLES1Impl cannot be cast to class com.jogamp.opengl.GL2ES2 (jogamp.opengl.es1.GLES1Impl and com.jogamp.opengl.GL2ES2 are in unnamed module of loader ‘app’)
in editor trying to render any opengl context.
With “MESA_GL_VERSION_OVERRIDE=2.1 %command%” build crashes:
Unable to create OpenGL context
FATAL:ENGINE: Could not open window (-2).
INFO:CRASH: Using libunwind.a
With launch option “prime-run %command%” everything seems working.
Thank you for providing additional information! I’m hopeful that we will be able to solve this soon. In the meantime you can downgrade to 1.2.179:
I just tried to reproduce this on an actual Linux machine (not a VM) running Ubuntu 20.04, but I couldn’t make it crash. 
09:50:13 ~/Downloads/Defold $ glxinfo | grep Mesa
client glx vendor string: Mesa Project and SGI
Device: Mesa DRI Intel® HD Graphics 4400 (HSW GT2) (0xa16)
OpenGL renderer string: Mesa DRI Intel® HD Graphics 4400 (HSW GT2)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 20.2.6
OpenGL version string: 3.0 Mesa 20.2.6
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 20.2.6
I didn’t have to do anything to launch the editor or engine. (i.e. no extra environment flags).
I’ll make a special version of the editor that prints out all the environment variables that it uses to launch the engine. Perhaps we find something there to pinpoint why the engine doesn’t launch properly.
For those helping out testing the linux build:
http://d.defold.com/archive/dev/d0d12b31d9f82ca9842c0bebe61a218b7cf23e12/dev/editor2/Defold-x86_64-linux.zip
This version outputs the environment variables when launching the engine.
You can use that output and compare it to what you get when you do a export in the Terminal. Hopefully we can detect some variables that trip up the dmengine.
$ wget http://d.defold.com/archive/dev/d0d12b31d9f82ca9842c0bebe61a218b7cf23e12/engine/x86_64-linux/dmengine
$ chmod +x dmengine
$ ./dmengine
This downloads the engine, changes the executable attribute, and then verifies that it launches correctly (i.e. creates a window and shows the debug app)
Create a test.sh with all the environment variables in it, (The ones the new editor output when you tried to launch the engine and it failed).
At the end of the script, we launch the engine.
E.g. something like this (test.sh):
export USER=mawe
export JAVA_CMD=java
... many more
#launch the engine
./dmengine
Run the script
$ sh test.sh
At this point, it should still fail, and we have a repro case.
Now, comment out the environment variables one by one, and test the script.
Once the engine starts running again, we’ll note the environment variables that we’ve removed. Some of them are problematic (but perhaps not all of them)
ping @ahmedmaawy, @ghpxi, @alcorrius
I ran both the editor and the dmengine separately on Ubuntu 18.04.5 LTS with no problems, if that’s at all helpful 
That’s good to know at least!
After quick review I can conclude next:
java.lang.ClassCastException: class jogamp.opengl.es1.GLES1Impl cannot be cast to class com.jogamp.opengl.GL2ES2
Unable to create OpenGL context
FATAL:ENGINE: Could not open window (-2).
INFO:CRASH: Using libunwind.a
Segmentation fault (core dumped)
Display: x11 server: X.Org 1.20.10 compositor: kwin_x11 driver: loaded: modesetting,nvidia
unloaded: intel,nouveau alternate: fbdev,nv,vesa display ID: :0 screens: 1
OpenGL: renderer: Mesa Intel HD Graphics 5500 (BDW GT2) v: 4.6 Mesa 20.3.4 direct render: Yes
I’ve read that modesetting driver can lead some problems. I’ll try to dig deaper the problem. But as I said previously, using nvidia graphics is a problem solver for me.
I don’t exactly understand this… I am not seeing anything in the terminal apart from the normal boot-up process when I launch these. Also, is there a list of ENV variables we should work against?
When I run this editor on Linux, from Terminal, using ./Defold, then I get output like this when pressing CTRL+B:
"MAWE debug command: " “/home/parallels/.Defold/unpack/d0d12b31d9f82ca9842c0bebe61a218b7cf23e12/x86_64-linux/bin/dmengine” []
“MAWE debug print env:” {“PATH” “/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin”, “XAUTHORITY” “/run/user/1000/gdm/Xauthority”, “XMODIFIERS” “@im=ibus”, “GDMSESSION” “ubuntu”, “XDG_DATA_DIRS” “/usr/share/ubuntu:/usr/local/share/:/usr/share/:/var/lib/snapd/desktop”, “DBUS_SESSION_BUS_ADDRESS” “unix:path=/run/user/1000/bus”, “PS1” "\t \[\033[32m\]\w\[\033[$(acolor)m\] $(git_branch)\[\033[00m\] $ ", “XDG_CURRENT_DESKTOP” “ubuntu:GNOME”, “JOURNAL_STREAM” “9:40701”, “DM_SERVICE_PORT” “dynamic”,…
Also, is there a list of ENV variables we should work against?
No. But my current theory is that somehow, some variable(s) gets added to the environment before launching the engine.
I base it on the fact that you can launch the engine as a stand alone executable from the Terminal without problem, and then when it’s launched via the editor, it fails.
The only way I can think of that they differ, is the environment they’re executed in.
For ./Defold does this make any sense?
Picked up JAVA_TOOL_OPTIONS:
Picked up _JAVA_OPTIONS:
Perhaps, I’m not entirely sure. We do bundle our own java runtime with the editor so technically it shouldn’t need outside settings.
But the question is, are they affecting the launch of dmengine?
Issue-5054 - Fixed : Improve detection of require() calls in Lua modules and scripts
Any way to ignore it?
I have some lua scripts in project, that i use. That scripts use my os lua. And libs from luarocks.
local requiref = require --in previous version that was enough to ignore that check
local lfs = requiref "lfs"
local cjson = requiref "cjson"