Note: the SDK does not need advocates. It needs contributors.
2 Likes
Yes, sad truth too. Currently lacking behind, yes yes. I see the build system being the biggest problem there. It is frankly intimidating to try and get into it. I should try again to convert it to Maven…
1 Like
Replacing 25 year old tech with 20 year old tech. Hmm… but SDK contribs should be its own thread. It’s separate from the engine.
1 Like
I know. But it is the best there is with NB. And it works. Already offers features and ease of use comparable to Gradle. Nothing is sexy there. Netbeans. Outcast. But all may not know that so we might just get away with it 
All the other projects trying to create an SDK have failed. The Intellij plugin, dead. All the other non IDE based SDKs also dead as far as I know. It is just a huge undertaking. No matter what is under the hood (bonnet ).
1 Like
Yes, we could create a setup form similar to LWJGL. If you want to take on that task, please go right ahead.
I still think adding library snapshots to the Engine would be valuable for newcomers. In general, newcomers favor built-in libraries (such as jme3-nifty and jme3-jbullet) over “supplementary” ones (such as Lemur and Minie). Rather than piece together a bunch of unfamiliar libraries that might have incompatibilities, they’d prefer to start with a set that have all been packaged and tested together, even if it’s incomplete and/or not the latest releases.
I had a comparable newcomer experience when I switched from Windows to Linux in 2019. Rather than piece together a bunch of Linux packages, I started with the Mint distribution. It didn’t include the printer support I needed, nor the latest releases of Java and Blender, but it enabled me to boot without knowing anything about kernel versions and package managers.
2 Likes
Nice but a few questions:
- this look like the JME SDK purpouse. We might as well work on that instead.
- who will actually choose the libraries version to snapshot and test them?
- who will review or include the documentation/samples to make sure they match the bundled versions?
1 Like
Clearly, including a few default library versions is a WAY smaller task and affects a LOT more people than fixing all of the issues with the SDK.
1 Like
Sorry for derailing the thread, but I thougth we were talking about providing a “quick solution for newcomers” who just want to download something and be ready to develop.
I didn’t mean “Fixing all the issues” or even “mantaining the SDK”. Just “bundle a version that can build & run the examples”
EDIT: This might become the “JMonkeyEngine starter” to clarify its purpouse
There seems to be plenty of interest in issuing another release of the Engine. Let’s keep the discussion going.
Meanwhile, UNLESS CONCERNS ARE PROMPTLY RAISED, I propose to designate myself as release manager for a v3.5 Engine release, the contents of said release still to be determined.
Here’s a proposed action plan for the release:
- Create a “v3.5.0” Engine milestone at GitHub, without a due date.
- Target closed issues and PRs to the new milestone if they’ve been solved/integrated since v3.4.
- Open issues as needed for ideas that emerge (or have emerged) from this discussion.
- Target open issues and PRs to the new milestone if they seem like promising candidates.
- Publish an alpha version for testing, with a list of changes since v3.4.0 .
- Announce a feature-freeze date.
- After feature freeze, create a “v3.5” branch at GitHub and publish a beta version for testing.
- During beta test, integrate low-risk bug fixes from master into “v3.5”.
- Announce a code-freeze date.
- After code-freeze, publish the “v3.5.0” release.
A major Engine release is a large undertaking, so it’ll have to be a team effort. Please contribute to the effort by:
- continuing to discuss the release here,
- opening and discussing issues at GitHub,
- opening pull requests,
- reviewing pull requests,
- testing alpha and beta releases, and
- updating the Wiki.
While it’s likely I’ll do all these things to some extent, I’d better not be the only one!
7 Likes
What about user issues and pull request submission to snapshots, should they be allowed to submit them on the engine page? (Just a heads-up!)
1 Like
If someone submits an issue/PR against a snapshot library, we should direct them to the developer’s repo (assuming it’s still maintained) and close the issue/PR.
If the developer’s repo isn’t maintained, then have a choice. We either maintain the library ourselves (in which case issues and PRs would be welcome) or drop the library (in which issues/PRs would be quickly closed).
But this is starting to look like a moot issue. Unless there’s strong support for library snapshots in the Engine, it’s not going to happen.
2 Likes
Good point about the SDK. For instance, I believe the latest SDK includes Heart and Minie. But maybe the SDK isn’t the best/only start for newcomers. I’ve opened a new topic to discuss getting newcomers started.
Engine content is the responsibility of the Engine team (between releases) or the release manager (during a release). They would decide which snapshots (if any) to include.
Testing would be performed (and documentation would be updated) in the same manner as other libraries included in the Engine: by volunteers led by the Engine team or release manager.
But I reiterate: library snapshots aren’t going to happen without strong support from the community.
1 Like
Do we still have custom skeleton from code support in the current version?
I’m not clear what you mean by “custom skeleton from code support”. Are you talking about animation, or something else? Please elaborate!
1 Like
I want to know, when will the next stable version of the engine SDK be updated? 
That would be a separate topic. The SDK and the engine are separate.
2 Likes
I have another suggestion/need.
Would it be possible to have a simple running Jar/code that is doing nothing else except converting the models to *J3O files ? This is the only reason for me to work with the SDK. Having a way to make those files without the SDK would be nice.
I am sure there is a reason for *J3O files, but I never fully understand why the format is needed at all.
For me this extra step of converting the models is something I have to accept.
2 Likes
Because it’s more efficient and faster, etc… and slightly harder for folks to steal your assets.
3 Likes
The ability to create animated skeletons by defining the bone weights and position with mesh data the way the custom mesh tutorial shows for version 3.2.
I have not used before the old animation system, but seems you are asking for a migration code for the Skeleton Control (Armature now, including joints instead of bones, …etc) if so, there is an AnimMigrationUtils you can look it up.