Hello dear helping Monkeys :chimpanzee_closedgrin:,
With this thread we try to coordinate our powers to maintain the sdk as good as possible.
The goal is to list the sdk-submodules so everyone who wants to maintain/help out with it can put his name onto it.
That way everyone can clearly see where we are missing manpower and/or what features to expect broken in the SDK (when unmaintained).
Apart from that, we always enjoy even the smallest help on all modules, so feel free to:
Try to tear the SDK apart (in order to find bugs)
Submit Pull Requests
Contribute in any other possible way
Note that for now everyone is welcome to become a maintainer, as long as he can devote some time into investigating possible bugs and digging a bit in the source code.
Don’t worry: If you’re stuck or generally have no clue, just create a topic and we all try to work on it. However please try to achieve something on your own.
Since we are a bit uncertain on how the future of the SDK should look like, feel free to comment here if you plan to work on your own whatever so we don’t end up with 1234 seperate Material Viewers.
Submodules
jme3-core:
No dedicated Maintainer
jme3-android:
No dedicated Maintainer
jme3-angelfont:
No dedicated Maintainer
jme3-assetpack-support
No dedicated Maintainer
jme3-blender (.blend Filetype, see also: jme3-model-importer)###
This shouldn’t break as it’s only the SDK-Integration (the functionality is part of the engine itself) No dedicated Maintainer
jme3-cinematics
No dedicated Maintainer
jme3-code-checks
No dedicated Maintainer
jme3-core-updatecenters
No dedicated Maintainer
jme3-dark-laf
No dedicated Maintainer
jme3-desktop-executables (Deployment)
No dedicated Maintainer
jme3-documentation
No dedicated Maintainer
jme3-ios
No dedicated Maintainer TODO: Merge the Plugin source (Google Code?) into the new Repo
jme3-gui (Nifty GUI Editor)
No dedicated Maintainer
jme3-lwjgl-applet (Applet Support)
Note: This will be deprecated No dedicated Maintainer
jme3-materialeditor
No dedicated Maintainer
jme3-model-importer
This shouldn’t break as it’s only the SDK-part (the functionality is part of the engine itself) No dedicated Maintainer
jme3-navmesh-gen
No dedicated Maintainer
jme3-obfuscate
No dedicated Maintainer
jme3-ogretools / jme3-ogrexml
Not really urgent since we recommend the .blend No dedicated Maintainer
Note the model import plugins don’t really need anything apart from a working jME importer, only exception is the jme3-ogretools one which uses the command line ogretools to do its work (advanced OgreXML import).
I think that we don’t need an applet maintainer since Oracle will drop support for applets soon.
I can’t really say I want a dedicated module. I’ll scout the issues and if I find anything that I think I can fix, I’ll try to fix it unless someone already works on it.
Unless someone requests it, I’m not planning to add new functionallity (for now).
I think it’s definitely a good idea to structure development like this, so the SDK can live on!
I will try to get into SDK development when I have a bit more spare time. But I will first have to get into building it, before digging into the actual code…
Would be great if there were some guides on the source code itself, so people who try to fix things can get more easily into it and not everyone has to read through the whole source code each time.
Thanks again for putting this together @Darkchaos!
In addition to figuring out maintainer coverage, it’s equally important that we identify projects that will be:
a) maintained in a new form
b) deprecated entirely
For example, the applet module is probably safe to yank out. If there is one project out there still using that they’ll have to build support for that into their own project. Applets are not generally good practice and only make sense for extremely narrow use cases, ergo it shouldn’t add to our maintenance burden.
As for “maintained in new form”, the jme3-terrain-editor is being reinvented in @methusalah’s OpenRTS project, and I think it’s a great fit. RTS games is the de-facto use case for this type of terrain editor, so it makes sense that it’s maintained as a subset of the OpenRTS project, and not as a general purpose feature of jME.
You mean as in more comments in the Source-Code so someone reading it knows what it does?
Or rather a Guide on where to find what in Code?
As for the building: Don’t worry, it’s only one command you have to type
First of all: Complete ACK for Deprecating Applets, we should definately do that.
However I don’t think that removing (i.e. forbidding the maintainance of) the terrain editor is a good thing.
Many non-RTS Games could make use of it: I’ve seen many flight-simulator games, (MMO)RPGs and even an FPS could use it for mountains. It’s simply more efficient than using multiple Geometries for that.
If you can use openRTS without all the RTS-Stuff (as a plain Terrain Editor), I’m fine with it replacing the Terrain-Editor however I don’t think we should choose between “maintaining in a new form” and “maintaining as is” but rather allow both because in the end it’s the users spare time they spend. So when someone still want’s the old Terrain-Editor, he should be able to go for it.
Yes and no, I didn’t add it to the list as it didn’t have a submodule in the SDK (and so I overlooked it basically).
My guess is that there wasn’t any iOS-Support in the SDK but you had to roll XCode to deploy your app?
Though I’m not an expert at this, so I’ll wait for someone correcting me.
Maybe it’s something generally broken with the engine itself?
Unfortunatly, OpenRTS terrain editor is not using JME terrain but a home made terrain framework, which is very RTS-specific (no quad trees, no LOD, no field of view, tiny maps). It won’t be usable for any first or third person view game without a lot of refactoring.
iOS is a separate plugin / module that was available though the update center (or rather still is for 3.0). I don’t know where it was imported to from its original jmonkeyplatform-contributions.googlecode.com location though. Its a combination of ANT tasks to cross-compile the code, some binary compilers for the cross-compilation and base templates for XCode to actually deploy the app. (Plus some ANT tasks in the plugin to actually compile the cross-compiler from sources with OpenJDK etc.)
Edit:
Working on it its a bit cumbersome as parts of the code are in the core engine (jme3-ios) and parts are in the plugin (especially the native code). Easiest way to work on it is to open the plugin project with a reference to a local build of the SDK.
I’m thinking of a Wiki-page, something like “SDK Developer Introduction” or “How to work with the SDK source for newbies”
Imagine a JME user that knows a bit about how to work with the engine, uses the SDK, but has never worked with Netbeans sources. At one point he may be thinking (for example) “I want to improve on the Scene Composer, where do I have to start and where is all the relevant code at?”. Or another example like “I wrote this basic function that changes all the materials of a j3o file, how do I turn this into a right-click menu option in the asset browser?”.
Some guidelines like this would really kick-start SDK development I think.
Well this whole thing is about problems with maintaining the SDK, if there was manpower to additionally write tutorials about it this wouldn’t be necessary at all ^^
Also if you have a particular problem, there are like 1000 Posts in the official Netbeans Forums.
Right-Click Options are Actions you have to add as Annotation or in the layer.xml
Other than that, UTSL (Just copy what JME already does, it covers most cases already, in your example the “Edit in SceneComposer” for example)
That remembered me that we gotta add an edit terrain button when a terrain node in sceneGraph explorer (I think it’s called like that) is right clicked. It’s so annoying that you have to right click the j3o instead of the terrain itself.
EDIT: I’ll create an issue on github so we don’t forget.
I’d be happy to help with the documentation. JME is in desperate need of updated examples. To be frank the old code samples in the wiki really push you in the wrong direction of where to start.
Theres a big button in the top bar to open the terrain editor. I don’t think it makes sense to put it in the Scene Explorer because that is where self-contained actions for the Scene Explorer live (i.e. across all editor plugins).
