Hey fellow monkeys,
As some of you might know, we’ve had a few problems with Travis in the last few months.
These issues all revolved around exhausting the build time and disk space. Why? Because we always bundle an appropriate JDK and Blender version with each installer.
If you don’t need these, you can just download the platform independent/portable zip.
If you downloaded
v3.2.0-stable-sdk before yesterday evening (13th January 2018), then please re-download the installer as we cannot guarantee that it works flawlessly (since travis quit in the middle of the build, producing half-finished products).
There is not much to say at this point about the patch notes, because there were only small fixes and additions (adjustable view panes, printing the camera location), the major feature is the new engine version.
See the release here: https://github.com/jMonkeyEngine/sdk/releases/tag/v3.2.0-stable-sdk1
Feel free to collect some patch notes if you want to and I’ll include them.
Nomenclature of the SDK (Versioning Scheme)
Since some people mix up the engine version and the sdk version I’m explaining it shortly:
v.3.2.0-stable as engine version and
sdk1 as SDK Version, this means it’s the first SDK Release based upon
v3.2.0-stable. So the next SDK Release would be
In the next few days I will open another thread about a Docker Image I’ve created to build the SDK locally. I’ve required that to “fake” travis, in order to debug a few issues and to see which files take up what disk space during which build phase. This helped me reducing the Diskspace from 21G to 7.3G
So what I’m going to do is push it to a public repository and open up a dockerhub account, so you can too easily build each SDK Release installer.
This is helpful if you’d want your game editor to be based off the SDK or ship your engine fork with easy installers for all your team members OR: If the releases from github wont work for you, you could build them on your own.
Do note that this is not the best way to debug the SDK though, since docker won’t let you start a X11 Display Application that easy. Also the scripts are not made to build from a specific commit, instead they take specific engine tags like
The Most Important: Looking for Contributors.
Just like the Engine, we need contributions. These contributions can be as small as just reporting bugs (like @grizeldi always does), up to a dedicated maintainer/contact person for components like the SceneComposer, the Android Support etc.
Why the SDK and not the Engine? While I agree that Engine fixes are more important, the fixes on the SDK are easier in terms of non-programmer-skills. You don’t need profund knowledge about (Vector-) Maths, 3D Engines in general or anything.
There are easy things as fixing javadoc (missing parameter annotations) up to the SceneComposer (which does only require Java Knowledge and time to get an overview over the many interacting classes).
Just give it a try, just look at the code and see if you can find anything which interests you.